On Mon Nov 9, 2026 at 3:14 PM CET, Sterling Windmill wrote:
>> Hello, there is a github issue tracking this and a patch[2] (by me)
>> currently pending final review.
>>
>> Can you see if [2] has the same behaviour you expect?
>>
>> [1]: https://github.com/kdave/btrfs-progs/issues/329
>> [2]: https://lore.kernel.org/linux-btrfs/20261103194734.598182-1-koray.fra@gmail.com/T/#t
>
> Hi koraynilay,
>
> Thanks for pointing me at it. From reading the series (I haven't built
> or run it), it looks like it solves a related but different problem.
>
> It lets the property carry a level, which is useful, but the only
> inode.c changes are to how the level is chosen. inode_need_compress()
> is untouched, so a file with btrfs.compression=zstd:3 would still go
> through btrfs_compress_heuristic(), because FORCE_COMPRESS still only
> comes from the mount option. I would expect to keep getting the 31G
> result from my table, unless I've missed something.
>
> What I'm after is a way for the property to skip the heuristic the
> way compress-force does, so that one subvolume can behave like
> compress-force on a filesystem mounted with plain compress.
>
> Since your series defines the "algo:level" syntax, would something
> like "zstd:3:force" fit as a follow-up on top of it? The alternative

I read the code a bit (and bounced some ideas with gemini) and I think a
"force:algo:level" would work well.

This, compared to "algo:level:force", would also allow a "force" value
(handled like "none" is already handled), that lets the user set *only*
the compress-force, without having to specify algo:level, so inheriting
from -o compress=, and the parsing would be as simple as if ("force")
str += 6, where str is the xattr string that gets then parsed by the
rest of the code (in compression_apply()).

> I can see is a separate property, which would only need a small
> change to inode_need_compress() and wouldn't depend on your series,
> at the cost of having two properties for one setting. I'd be glad to
> hear which you or others on the list would prefer.

A separate property would probably be more work/less easy to handle, as
it also needs to get checked for conflicts like btrfs.compression=none
and btrfs.compression_force=yes.


It should probably be a separate patch, but it'd depend on my patch
series, so not sure if I should just make a v7 with that or not.

Best,
koraynilay

>
> Thanks,
> Sterling