Just wanted to report on mine, so far so good! I have (using local backend on ext4 filesystem) a 4TB drive, 8TB drive, and a 1TB drive (in a portable system), all running s3ql with a variety of workloads (some movie storage -- I know s3ql won't do anything to shrink or dedup that but OK... rsync backups, VirtualBox activities, both .ova files and running VMs out of there, some source code, some games as well.) Nothing to report! Unmounted filesystem(s), updated s3ql. The s3qladm upgrade process was quick and painless, on the 2GB database it took a minute or two, on the others it was nearly instantaneous. It shrunk the databases about 10-15%. I decided to fsck.s3ql --force the filesystems too, no problems. The 8TB has a lot of duplication due to rsync backups on it, about 8.8TB data on the 8TB drive using 5.23TB disk space. This one the DB is now 1.9GB and shrunk about by 200MB. 4TB, it's like 90MB now, it shrunk about 9MB. It definitely mounts, unmounts, and fscks faster (since there's 1 fewer tables for it to read in, write back, or check.) I didn't think of doing any benchmarks but "seat of the pants" it does seem a bit faster in use too; not a surprise, when you're pushing the IOPS on there one potential "choke point" are s3qlite synchronous writes, and removing one table means that much less stuff for s3qlite to have to write out.
-- You received this message because you are subscribed to the Google Groups "s3ql" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/s3ql/CAOuPqTEjw%3DhJ-k_MXUyPuruCo-ts8ssY7WiyEXyF0JFk5ESk2w%40mail.gmail.com.
