Use force compression on btrfs

[JSE]

Currently, when you format a disk or pool to btrfs in unraid, an option is provided to enable compression.

While unraid does use the efficient zstd compression with the default level 3 compression level which I think is a very optimal default, it's using the `compress` mount option rather than `compress-force` option on the filesystem. 

 

Btrfs has a very rudimentary algorithm when you use the `compress` mount option where it will abandon even attempting compression on a file if the first few KiB is not compressible. This results in a lot of files that have portions that could compress not get compressed, and in a lot of cases behaves as if you didn't have compression enabled whatsoever. It makes the current unraid compression behavior to arguably be not very useful.

 

Now if you were using some of the other algorithms like zlib, force compression could actually have a negative impact. However, zstd compression is smart enough to not store any compression it attempts if it doesn't yield an improvement in storage.

 

This request is thus to use the compress-force option instead so compression actually happens on files that have headers that can't compress, or at least provide an option to enable force compression so those of us who do wan't compression can force it (such as a check box or an alternative option). This yields much more space savings for me than the current option, but I currently have to resort to remounting my disks with the compress-force option via the shell or a script rather than rely on the option unraid provides.

[PeteAsking]

For BTRFS volumes I see people having issues with BTRFS. This is because I think people dont know to do a balance/scrub periodically and a defragment.

 

For example I have a userscript that runs on the 1st day of every 2nd month (6 times a year basically):

 

#!/bin/bash
date > /mnt/btrfsprotect/domains/Defrag.log
btrfs fi show /mnt/btrfsprotect >> /mnt/btrfsprotect/domains/Defrag.log
btrfs filesystem usage /mnt/btrfsprotect/ >> /mnt/btrfsprotect/domains/Defrag.log
echo ----start---- >> /mnt/btrfsprotect/domains/Defrag.log
btrfs filesystem defragment -r -v -clzo /mnt/btrfsprotect/ >> /mnt/btrfsprotect/domains/Defrag.log
echo ----end---- >> /mnt/btrfsprotect/domains/Defrag.log
btrfs fi show /mnt/btrfsprotect >> /mnt/btrfsprotect/domains/Defrag.log
btrfs filesystem usage /mnt/btrfsprotect/ >> /mnt/btrfsprotect/domains/Defrag.log
date >> /mnt/btrfsprotect/domains/Defrag.log

 

The relevant line is this: btrfs filesystem defragment -r -v -clzo /mnt/btrfsprotect/ and the other lines setup logging I can review. It also has the output of "Free (estimated): " which is more useful in determining free space available.

 

This allows me to defrag the volume and compress archived files and so on, and for the scrub and balance I run on a schedule Every Sunday a balance on the array which is quick as it never finds unbalanced files (so far) at 3AM and every Monday a Scrub at 3AM (Duration: 0:26:05) which checks for errors.

 

Doing this I have never had an issue with BTRFS. I use Raid1 with 3 disks and if a disk failed, then it would at least rebalance on the next run to the remaining disks (and I would quickly realize a problem of low disk space when this happened).

 

Just some tips I have found worked well for me for as long as btrfs has been available on unraid (I converted to it the moment it was available a few versions back). Hope this helps you.

Edited January 24 by PeteAsking

[primeval_god]

Defragmenting is not recommended for BTRFS volumes under normal circumstances, especially not if snapshots are being used. Defragmenting breaks CoW sharing between files, snapshots etc. It certainly should not be done filesystem wide.

[PeteAsking]

1 hour ago, primeval_god said:

Defragmenting is not recommended for BTRFS volumes under normal circumstances, especially not if snapshots are being used. Defragmenting breaks CoW sharing between files, snapshots etc. It certainly should not be done filesystem wide.

On unraid nocow is the default so its not a problem. If you override that and use cow and snapshots then I agree its not appropriate. However this is not the default setup for unraid. I think the only issue is if you use snapshots and not cow. (The issue is just that more space will be used as the filesystem sees each snapshot as a different copy of a file each taking up space as opposed to sharing space). 

Edited January 24 by PeteAsking

[JorgeB]

NOCOW is no longer the default, for some time now that the default is COW, but there will old installs that are still using NOCOW, though note that snapshots still work with NOCOW.

[PeteAsking]

Ok interesting. I was unaware it had changed. In terms of defrag, if not using snapshots it is pretty useful as the amount of space reclaimed is significant when compressing files. This is normally many gigabytes. 
 

if you do use snapshots, I agree it would increase the space (have the opposite effect) as it would break deduplication. So it would depend on your use case. 

Edited January 24 by PeteAsking

[primeval_god]

48 minutes ago, PeteAsking said:

if not using snapshots it is pretty useful as the amount of space reclaimed is significant when compressing files. This is normally many gigabytes. 

I would disagree with this. The usefulness of compression is highly dependent on the type of files you have. For media files, which likely make up the vast majority of files stored on unRAID NAS devices, filesystem compression does very little as the files are already highly compressed.

[PeteAsking]

16 minutes ago, primeval_god said:

I would disagree with this. The usefulness of compression is highly dependent on the type of files you have. For media files, which likely make up the vast majority of files stored on unRAID NAS devices, filesystem compression does very little as the files are already highly compressed.

Sure, however you have no way of knowing if media files are the majority of files stored by all unraid users, that is a major assumption on your part. For many, it helps, myself included. I saved 80GB on the last run for instance, that is over a 2 month period. For myself, that is something I cant really just give up as I use my NAS every day and would fill it up at a faster rate if I did not.

[JSE]

On 1/24/2024 at 3:09 PM, PeteAsking said:

On unraid nocow is the default so its not a problem. If you override that and use cow and snapshots then I agree its not appropriate. However this is not the default setup for unraid. I think the only issue is if you use snapshots and not cow. (The issue is just that more space will be used as the filesystem sees each snapshot as a different copy of a file each taking up space as opposed to sharing space). 

As @JorgeB mentioned NOCOW is no longer default for any shares, but even if you set NOCOW, you need to keep in mind that not only is redundancy compromised with the use of nocow, compression will not work whatsoever on those files. Compression needs copy on write to function. Nocow is equal to nocsums and no compression.

 

On 1/24/2024 at 4:13 PM, primeval_god said:

I would disagree with this. The usefulness of compression is highly dependent on the type of files you have. For media files, which likely make up the vast majority of files stored on unRAID NAS devices, filesystem compression does very little as the files are already highly compressed.

This is true, however the zstd compression algorithm is more than fast enough on most modern CPUs to discard any files that can't be compressed and store them normally. For the files that are compressible.

Alternatively unraid could use the `btrfs property set /path/to/share/on/btrfs compress zstd` on a directory or subvolume which will work identical to compress-force on the filesystem wide option. This would allow users to set compression on a per-share basis much like nocow. It doesn't allow setting a compression level, however given unraid defaults to 3 anyway, this option also defaults to 3 which I'd argue is a good default anyway.

 

Given that ZFS supports compression on a per-dataset basis this might be a better solution rather than per filesystem basis in the long term, however the option would need to be set at share creation time to be most effective. Given that btrfs should be using subvolumes for shares this should depend on this feature request being implemented as well (though this option doesn't technically need to be on a per-subvolume basis like it does for ZFS datasets).

IMO this would be an ever better way of handling compression as you could leave compression disabled for media shares so no CPU time is wasted whatsoever on media, but have it enabled for shares you know compression would be beneficial as it would use the force compression without any mount options at all.

Edited February 4 by JSE