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 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
signature.asc
(application/pgp-signature, 228 B)
-----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQSgVimKafU5DQMcjcDmj22qf5IGXAUCankj9gAKCRDmj22qf5IG XOliAQClXyJBVdGPtdHsTPKFXVbTqpk26UFnG2Ai2xFpzRP3PAEAjsXtj/k4Y6KV k7P1SWYiCZPEq97FLFk/GOHz6F+6NQ4= =oMiJ -----END PGP SIGNATURE-----