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.

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"

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.