I have a icsci mount with btrfs on top. It has 3 subvolumes for my 3 data sets, which are: home photos/videos, media (books, games, movies, shows, music) and persistent homelab data. If I turn on compression, are their any considerations I should make besides perhaps aligning compression type with the data set for maximum compression? Should I not compress certain things?
I do incremental backups to gdrive with Duplicity which has compression by default. Problems there? I would assume Duplicity would think the newly compressed data is “new” so I should do a new full backup and increment from there.
There is a simple decision logic: if the first portion of data being compressed is not smaller than the original, the compression of the file is disabled – unless the filesystem is mounted with -o compress-force . In that case compression will always be attempted on the file only to be later discarded.
basically, if you have a subvolume that is 50% video / 50% text - no harm; if it’s 90/10 … maybe it becomes wasteful.
fwiw I’m using compress=zstd in my fstab for my / (root) and this shows up as:
Oh good consideration regarding the “first Portion” bit. Makes my mismatched datasets possibly behave differently than I would expect. Thanks for that. I guess I’ll copy over some data and run some tests with it. Overall it sounds like I won’t hurt anything, just that something’s won’t compress well.
you can try compressing some data even if you don’t have btrfs mounted with compression options, … see how it goes … if you don’t like it you can uncompress it.
sudo btrfs fi defrag -c zstd -r /books should just work regardless of mount options.
You can use chattr +c or chattr +X on a directory see man 5 btrfs and man chattr.
One thing to keep in mind is the interaction between compression and cow, compression basically forces copy-on-write and it force enables checksumming .