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

[Zygo Blaxell <ce3g8jdj@umail.furryterror.org>]

On Mon, Aug 10, 2026 at 11:27:49AM +0930, Qu Wenruo wrote:
> 
> 
> 在 2026/8/10 11:27, koraynilay 写道:
> > On Mon Aug 10, 2026 at 3:54 AM CEST, Qu Wenruo wrote:
> > > 
> > > 
> > > 在 2026/8/10 10:35, koraynilay 写道:
> > > > 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.
> > > 
> > > To be honest, with the proper XATTR compression level specification, I
> > > think we should even deprecate compress= mount option, and make the
> > > XATTR one the only recommended way to specific compression.
> > 
> > Ah, and in that case, to set compression on the whole fs use btrfs prop to
> > set it on the root?
> 
> Yep.

I am vehemently opposed to deprecation of a feature that will require
updating _billions_ of inodes per server to get the same effect, when
the filesystem was previously able to handle a 4-level hierarchy of
compression options with "defer to next level" since the beginning.

I will maintain a fork if I have to.  Hard NAK.

We can have clearer documentation about how options are processed,
and clearly what options mean "look up to the next level" vs "use the
default" or "use the locally defined value."

> > > There are already too many corner cases with mount option.
> > > 
> > > IMHO, a good design should allow and only allow the best way to do a thing.
> > > 
> > > And option 3 matches perfect for the XATTR only compression future. It
> > > still allows old XATTR to work, have a very sane default level, very
> > > explicit and clear independent from whatever stupid mount option there
> > > could be.
> 
> 
>