Re: [RFC] btrfs: forcing compression per inode via the compression property?

["koraynilay" <koray.fra@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3742 bytes --]

On Mon Nov 9, 2026 at 2:51 PM CET, Sterling Windmill wrote:
> (Resending as plain text; the list rejected my first copy as HTML.
> Sorry for the duplicate to those on Cc.)
>
> Hi,
>
> compress-force can only be set for the whole filesystem. I would like
> to apply it to one subvolume and leave the rest of the filesystem on
> plain compress. Before writing a patch, I'd like to know whether this
> would be welcome and what form it should take.
>
> My filesystem (kernel 7.3.3, 10-device RAID10) holds both raw disk
> image backups and large, already-compressed video files, and these
> want opposite settings.
>
> The images need compress-force. I copied one image (about 60G of data
> in a sparse 249G file) three times with
> "cp --reflink=never --sparse=always". Sizes are from compsize:
>
>   mode                      extents   on disk   stored raw  zstd in->out
>   compress-force=zstd:3     615,577     23G        11G      48G -> 12G
>   compress=zstd:3 + prop    492,796     31G        27G      33G -> 4.6G
>   compress=zstd:3           218,911     60G        60G     944K -> 296K
>
> "prop" is btrfs.compression=zstd. The last copy ended up with
> NOCOMPRESS set. This is one image and one sequential write, so I would
> not read much into the exact percentages, but the property costs about
> 35% more space here than compress-force. I have not measured how much
> of that comes from the heuristic's sampling and how much from data
> that is compressible despite its byte distribution.
>
> The video pays for compress-force. An 82G file had 169,776 extents and
> read sequentially at 270 MB/s. After "btrfs filesystem defragment
> --nocomp" it had 666 extents and read at 622 MB/s. That works, but it
> has to be repeated for new files and it breaks reflinks.
>
> As I read inode_need_compress(), FORCE_COMPRESS is only ever taken from
> the mount option, and a property always goes through
> btrfs_compress_heuristic(). compress_file_range() already avoids
> setting NOCOMPRESS when prop_compress is set, so a per-inode force
> seems to need little more than this (hypothetical field, untested):
>
> 	if (btrfs_test_opt(fs_info, FORCE_COMPRESS) ||
> 	    inode->prop_compress_force)
> 		return 1;
>
> With that, I could mount with compress=zstd:3 and set force on the
> backup subvolume, relying on the usual property inheritance.
>
> Questions:
>
> 1. Is a per-inode force something you would accept, or would you
>    rather see the heuristic improved for this kind of data?
>
> 2. What should the interface be? The per-inode compression levels
>    series [1] adds "algo:level" to the same property. Would a suffix
>    such as "zstd:3:force" be acceptable, or a separate property? How
>    much does the behaviour of older kernels reading the value
>    constrain this?
>
> 3. How should it interact with NOCOMPRESS? I assume setting force
>    would clear the flag and take precedence over it. The 2020 thread
>    on compress-force and per-inode settings seems to have left the
>    three-state question open:
>    https://lore.kernel.org/all/b92d0141-f68f-ce96-8099-e145ebc6f594@toxicpanda.com/T/
>
> 4. Should this wait until the levels series is settled?
>
> If there is interest, I am happy to write the patch and test it on
> this data.

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

Best,
koraynilay

> Thanks,
> Sterling Windmill
>
> [1] https://lwn.net/Articles/1096934/



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]