Jump to content

Use force compression on btrfs


Recommended Posts

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.

Link to comment

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 by PeteAsking
Link to comment
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 by PeteAsking
Link to comment

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 by PeteAsking
Link to comment
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.

Link to comment
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.

Link to comment
  • 2 weeks later...
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 by JSE
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...