Re: [PATCH 0/4] btrfs: add per-inode compression levels in xattrs

"koraynilay" <[email protected]>
Newsgroups org.kernel.vger.linux-btrfs
Message-ID <[email protected]>
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
signature.asc (application/pgp-signature, 228 B)
-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQSgVimKafU5DQMcjcDmj22qf5IGXAUCanpTtAAKCRDmj22qf5IG
XKJOAP9HwlylEvV8U7AvTMvqskWdsSkTtXYZ9GBaaSeThNRXeQEA6XA5ywJIzKTp
DmrGFdnpMBnwbXn/+z/lb1k94M6xYwk=
=OIJl
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.