kdave / btrfs-progs

Development of userspace BTRFS tools
GNU General Public License v2.0
527 stars 239 forks source link

Enhancement: compress-force xattr #696

Open Forza-tng opened 8 months ago

Forza-tng commented 8 months ago

As a complement to btrfs property set <file> compression [algo], it could be useful to have a force option of the same.

kdave commented 8 months ago

We have only the plain string in the properties and enhancing tha with anything, like level or the forcing flag would be an incompatible change, though easy to handle due to the string value. Just that kernel and progs could refuse the values and either behave unexpectedly or crash.

As the NOCOMPRESS flag is set automatically, this would have to be overridden in the code according the the property, but this would complicate the compression decisions which are already hard to follow in some cases.

Can you please describe the use case, e.g. for which type of files or if it's based on some external tool that picks which files would need it. Thanks.

Forza-tng commented 8 months ago

Hi The basic idea is to allow better compression on data that is not as performance sensitive and where the heuristics isn't helpful. It's similar to the wish for being able to compression level via xattr as well.

Since we can already set level in an xattr, just that the kernel doesn't yet read the level part, could we further add a f to the level part?

Something like:

btrfs property set somefile compression zstd:15f

The f would indicate force mode. Would something like this be possible without introducing compatibility issues? Current tools do accept setting such values.

❯ btrfs property set bees.3t_backup.log  compression zstd:15f

❯ getfattr -n btrfs.compression bees.3t_backup.log
# file: bees.3t_backup.log
btrfs.compression="zstd:15f"
kdave commented 8 months ago

Yeah something like that could work, the future-extensible syntax for the compression value would be "read from left as far as you can parse", which now would be the name, then ":number" and then the "f" eventually, but we can do the ":f" at once.

Curretnly kernel verifies the name, so this should work in a backward compatible way only ignoring the level.