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.


>>      https://wiki.tnonline.net/w/Btrfs/Compression
>
> The first URL doesn't even resolve here.
(for some reason it's down right now :(, it was up < 1 hour ago).

Best,
koraynilay