On Mon Aug 10, 2026 at 3:05 AM CEST, koraynilay wrote:
> On Mon Aug 10, 2026 at 2:51 AM CEST, Qu Wenruo wrote:
>>>>>> So either option 2 or 3 would be fine to me. Although I personally prefer
>>>>>> option 3 a little more, just because it's much cleaner code wise.
>>>>>
>>>>> Option 2 preserves legacy behavior that is 12 years old now, and it
>>>>> costs a single comparison in two 'if' statements.
>>>>>
>>>>> Option 3 makes an already confusing situation worse--it makes the
>>>>> underspecified behavior change depending on kernel version.
>>>>
>>>> One should never rely on something not documented in the first place.
>>> 
>>> Option 3 prevents existing mount-option compression level specifications
>>> from working when the attribute agress with the mount option; otherwise,
>>> they would be blocked by a btrfs.compression string that doesn't specify
>>> a level.  That's a _regression_.
>>
>> Let me be this clear, the current one nor option 2 is not working either.
>>
>> If the current algo is different from the XATTR algo, it will be 
>> whatever random number clamped to the XATTR algo for the current code.
>>
>> This applies to the option 2 solution. When mount option changed, the 
>> level will suddenly change from whatever previous mount option to the 
>> default.
>
> TBF, I can see how it could be useful (or rather, how it could be good
> to have it as an option) to have some files with btrfs.compression="zstd"
> and then use -o compress= to decide on the fly how much compressed the
> new data added to them should be.
> Both are (read: will be, after the per-inode patch) 1 command away, but
> there *might* be use-cases where mount is more suitable.
>
>

Hi,

after a little bit of discussion on #btrfs on IRC, kepstin and I drafted
a doc change[1] on a variant of option 2, a bit more clear and expanding
also on the per-inode level change.

Thanks


Best,
koraynilay

[1]: https://github.com/kdave/btrfs-progs/pull/1152