Package: python3.6-dedupsqlfs Version: 1.2.948-0rusoft7.4~debian7.1 Architecture: amd64 Maintainer: Sergey Dryabzhinsky Installed-Size: 3111 Depends: libc6 (>= 2.4), libgcc1 (>= 1:4.1.1), liblzma5 (>= 5.1.1alpha+20120614), liblzo2-2 (>= 2.02), libsnappy1, libstdc++6 (>= 4.1.1), python3.6, python3.6-pip-llfuse (>= 1.3.6), python3.6-pip-pymysql, python3.6-pip-recordclass Suggests: mysql-client | mariadb-client, mysql-server | mariadb-server Conflicts: dedupsqlfs-binary Provides: dedupsqlfs Filename: pool/debian-wheezy/amd64/python3.6-dedupsqlfs/python3.6-dedupsqlfs_1.2.948-0rusoft7.4~debian7.1_amd64.deb Size: 837864 MD5sum: 8e0b2001cc64e420aa63306019623111 SHA1: 9196224cc4aa96fcf7fe6363ba1a3c95adf614f5 SHA256: 7ed4aad61847964d97929e3659dd196d25ed8a2a18189d71067f28d406ac7952 Section: otherosfs Priority: extra Homepage: https://github.com/sergey-dryabzhinsky/dedupsqlfs Description: Deduplicating filesystem via FUSE and SQLite written in Python Development on DedupSqlFS began as a proof of concept to find out how much disk space the author could free by employing deduplication to store his daily backups. Since then it's become more or less usable as a way to archive old backups, i.e. for secondary storage deduplication. It's not recommended to use the file system for primary storage though, simply because the file system is too slow. I also wouldn't recommend depending on DedupFS just yet, at least until a proper set of automated tests has been written and successfully run to prove the correctness of the code. . What's new . - Filesystem data stored in multiple SQLite files. - Tuned SQLite connections. - Delayed writes for blocks (hashing and compression too). - Use "stream"-like writes and read of data blocks, don't store complete files in memory. - Cached filesystem tree nodes, inodes and data blocks. - New compression methods (some ported for python3): lzo, lz4, quicklz, zstd (ported); lzma, snappy. - Support for data storage in localy started MySQL server. Package: python3.6-dedupsqlfs-binary Source: python3.6-dedupsqlfs Version: 1.2.948-0rusoft7.4~debian7.1 Architecture: amd64 Maintainer: Sergey Dryabzhinsky Installed-Size: 13849 Depends: libc6 (>= 2.4), libgcc1 (>= 1:4.1.1), liblzma5 (>= 5.1.1alpha+20120614), liblzo2-2 (>= 2.02), libsnappy1, libstdc++6 (>= 4.1.1), python3.6, python3.6-pip-llfuse (>= 1.3.6), python3.6-pip-pymysql, python3.6-pip-recordclass Suggests: mysql-client | mariadb-client, mysql-server | mariadb-server Conflicts: dedupsqlfs Provides: dedupsqlfs-binary Filename: pool/debian-wheezy/amd64/python3.6-dedupsqlfs/python3.6-dedupsqlfs-binary_1.2.948-0rusoft7.4~debian7.1_amd64.deb Size: 3001584 MD5sum: 3cc7e79a5d498379f54af50a52c9b0db SHA1: 553b0d9421ce1707d7bb9c65b71d3263908c7144 SHA256: 094479430535744e7bd72ca214a342672c30229f8f8439473ae4d159e7542c34 Section: otherosfs Priority: extra Homepage: https://github.com/sergey-dryabzhinsky/dedupsqlfs Description: Deduplicating filesystem via FUSE and SQLite written in Python Development on DedupSqlFS began as a proof of concept to find out how much disk space the author could free by employing deduplication to store his daily backups. Since then it's become more or less usable as a way to archive old backups, i.e. for secondary storage deduplication. It's not recommended to use the file system for primary storage though, simply because the file system is too slow. I also wouldn't recommend depending on DedupFS just yet, at least until a proper set of automated tests has been written and successfully run to prove the correctness of the code. . What's new . - Build with Cython - Filesystem data stored in multiple SQLite files. - Tuned SQLite connections. - Delayed writes for blocks (hashing and compression too). - Use "stream"-like writes and read of data blocks, don't store complete files in memory. - Cached filesystem tree nodes, inodes and data blocks. - New compression methods (some ported for python3): lzo, lz4, quicklz, zstd (ported); lzma, snappy. - Support for data storage in localy started MySQL server. Package: python3.7-dedupsqlfs Version: 1.2.948-0rusoft7.3~debian7.1 Architecture: amd64 Maintainer: Sergey Dryabzhinsky Installed-Size: 3146 Depends: libc6 (>= 2.4), libgcc1 (>= 1:4.1.1), liblzma5 (>= 5.1.1alpha+20120614), liblzo2-2 (>= 2.02), libsnappy1, libstdc++6 (>= 4.1.1), python3.7, python3.7-pip-llfuse (>= 1.3.6), python3.7-pip-pymysql, python3.7-pip-recordclass Suggests: mysql-client | mariadb-client, mysql-server | mariadb-server Conflicts: dedupsqlfs-binary Provides: dedupsqlfs Filename: pool/debian-wheezy/amd64/python3.7-dedupsqlfs/python3.7-dedupsqlfs_1.2.948-0rusoft7.3~debian7.1_amd64.deb Size: 842738 MD5sum: 4318db48d8099d18f03520a4b06de959 SHA1: 4f33d0c2564a9e887e0c3d69799a58df0b0e019d SHA256: 45d4eed180c8436d85b0cc193fed510554be8ac76ba74ae332d8f64b43f8f1b3 Section: otherosfs Priority: extra Homepage: https://github.com/sergey-dryabzhinsky/dedupsqlfs Description: Deduplicating filesystem via FUSE and SQLite written in Python Development on DedupSqlFS began as a proof of concept to find out how much disk space the author could free by employing deduplication to store his daily backups. Since then it's become more or less usable as a way to archive old backups, i.e. for secondary storage deduplication. It's not recommended to use the file system for primary storage though, simply because the file system is too slow. I also wouldn't recommend depending on DedupFS just yet, at least until a proper set of automated tests has been written and successfully run to prove the correctness of the code. . What's new . - Filesystem data stored in multiple SQLite files. - Tuned SQLite connections. - Delayed writes for blocks (hashing and compression too). - Use "stream"-like writes and read of data blocks, don't store complete files in memory. - Cached filesystem tree nodes, inodes and data blocks. - New compression methods (some ported for python3): lzo, lz4, quicklz, zstd (ported); lzma, snappy. - Support for data storage in localy started MySQL server. Package: python3.7-dedupsqlfs-binary Source: python3.7-dedupsqlfs Version: 1.2.948-0rusoft7.3~debian7.1 Architecture: amd64 Maintainer: Sergey Dryabzhinsky Installed-Size: 13890 Depends: libc6 (>= 2.4), libgcc1 (>= 1:4.1.1), liblzma5 (>= 5.1.1alpha+20120614), liblzo2-2 (>= 2.02), libsnappy1, libstdc++6 (>= 4.1.1), python3.7, python3.7-pip-llfuse (>= 1.3.6), python3.7-pip-pymysql Suggests: mysql-client | mariadb-client, mysql-server | mariadb-server Conflicts: dedupsqlfs, python3.7-pip-recordclass Provides: dedupsqlfs-binary Filename: pool/debian-wheezy/amd64/python3.7-dedupsqlfs/python3.7-dedupsqlfs-binary_1.2.948-0rusoft7.3~debian7.1_amd64.deb Size: 3017154 MD5sum: 8863314576290d3203ceb40851900f1d SHA1: 52a36b79d884e6c8b0b22af3cebbfd13089004b6 SHA256: 757b4628cb92efb6d9141881abf7ca7aa0d1c7412fb358ee2877671513d9634c Section: otherosfs Priority: extra Homepage: https://github.com/sergey-dryabzhinsky/dedupsqlfs Description: Deduplicating filesystem via FUSE and SQLite written in Python Development on DedupSqlFS began as a proof of concept to find out how much disk space the author could free by employing deduplication to store his daily backups. Since then it's become more or less usable as a way to archive old backups, i.e. for secondary storage deduplication. It's not recommended to use the file system for primary storage though, simply because the file system is too slow. I also wouldn't recommend depending on DedupFS just yet, at least until a proper set of automated tests has been written and successfully run to prove the correctness of the code. . What's new . - Build with Cython - Filesystem data stored in multiple SQLite files. - Tuned SQLite connections. - Delayed writes for blocks (hashing and compression too). - Use "stream"-like writes and read of data blocks, don't store complete files in memory. - Cached filesystem tree nodes, inodes and data blocks. - New compression methods (some ported for python3): lzo, lz4, quicklz, zstd (ported); lzma, snappy. - Support for data storage in localy started MySQL server. Package: python3.8-dedupsqlfs Version: 1.2.948-0rusoft7.3~debian7.1 Architecture: amd64 Maintainer: Sergey Dryabzhinsky Installed-Size: 3105 Depends: libc6 (>= 2.4), libgcc1 (>= 1:4.1.1), liblzma5 (>= 5.1.1alpha+20120614), liblzo2-2 (>= 2.02), libsnappy1, libstdc++6 (>= 4.1.1), python3.8, python3.8-pip-llfuse (>= 1.3.6), python3.8-pip-pymysql, python3.8-pip-recordclass Suggests: mysql-client | mariadb-client, mysql-server | mariadb-server Conflicts: dedupsqlfs-binary Provides: dedupsqlfs Filename: pool/debian-wheezy/amd64/python3.8-dedupsqlfs/python3.8-dedupsqlfs_1.2.948-0rusoft7.3~debian7.1_amd64.deb Size: 834956 MD5sum: 69f0cada44cec72639171314dbb59b3c SHA1: 21f088c9e6441209e4943bbf7f68dfcab2868e15 SHA256: ff8b7f44f5a83bcc39bd3c74f1a28dbee7a2a4e13e3f8bd703bedfa476073821 Section: otherosfs Priority: extra Homepage: https://github.com/sergey-dryabzhinsky/dedupsqlfs Description: Deduplicating filesystem via FUSE and SQLite written in Python Development on DedupSqlFS began as a proof of concept to find out how much disk space the author could free by employing deduplication to store his daily backups. Since then it's become more or less usable as a way to archive old backups, i.e. for secondary storage deduplication. It's not recommended to use the file system for primary storage though, simply because the file system is too slow. I also wouldn't recommend depending on DedupFS just yet, at least until a proper set of automated tests has been written and successfully run to prove the correctness of the code. . What's new . - Filesystem data stored in multiple SQLite files. - Tuned SQLite connections. - Delayed writes for blocks (hashing and compression too). - Use "stream"-like writes and read of data blocks, don't store complete files in memory. - Cached filesystem tree nodes, inodes and data blocks. - New compression methods (some ported for python3): lzo, lz4, quicklz, zstd (ported); lzma, snappy. - Support for data storage in localy started MySQL server. Package: python3.8-dedupsqlfs-binary Source: python3.8-dedupsqlfs Version: 1.2.948-0rusoft7.3~debian7.1 Architecture: amd64 Maintainer: Sergey Dryabzhinsky Installed-Size: 12610 Depends: libc6 (>= 2.4), libgcc1 (>= 1:4.1.1), liblzma5 (>= 5.1.1alpha+20120614), liblzo2-2 (>= 2.02), libsnappy1, libstdc++6 (>= 4.1.1), python3.8, python3.8-pip-llfuse (>= 1.3.6), python3.8-pip-pymysql, python3.8-pip-recordclass Suggests: mysql-client | mariadb-client, mysql-server | mariadb-server Conflicts: dedupsqlfs Provides: dedupsqlfs-binary Filename: pool/debian-wheezy/amd64/python3.8-dedupsqlfs/python3.8-dedupsqlfs-binary_1.2.948-0rusoft7.3~debian7.1_amd64.deb Size: 2728726 MD5sum: fa611e4afe6f243f0d4887c23d916bc5 SHA1: b3af38819e8e186d002dd0d3283ca58624d59c93 SHA256: dd2333d08aaa4d67ed4ab254a39e3fc40128468f46988f0fcd7762f9151d85a0 Section: otherosfs Priority: extra Homepage: https://github.com/sergey-dryabzhinsky/dedupsqlfs Description: Deduplicating filesystem via FUSE and SQLite written in Python Development on DedupSqlFS began as a proof of concept to find out how much disk space the author could free by employing deduplication to store his daily backups. Since then it's become more or less usable as a way to archive old backups, i.e. for secondary storage deduplication. It's not recommended to use the file system for primary storage though, simply because the file system is too slow. I also wouldn't recommend depending on DedupFS just yet, at least until a proper set of automated tests has been written and successfully run to prove the correctness of the code. . What's new . - Build with Cython - Filesystem data stored in multiple SQLite files. - Tuned SQLite connections. - Delayed writes for blocks (hashing and compression too). - Use "stream"-like writes and read of data blocks, don't store complete files in memory. - Cached filesystem tree nodes, inodes and data blocks. - New compression methods (some ported for python3): lzo, lz4, quicklz, zstd (ported); lzma, snappy. - Support for data storage in localy started MySQL server.