]> git.hungrycats.org Git - linux/commit
btrfs: stripe_alloc: let the property accept a cache-less filesystem like the mount...
authorZygo Blaxell <ce3g8jdj@umail.furryterror.org>
Thu, 17 Sep 2026 04:16:22 +0000 (00:16 -0400)
committerZygo Blaxell <ce3g8jdj@umail.furryterror.org>
Thu, 17 Sep 2026 04:16:22 +0000 (00:16 -0400)
commitb72dc2da0d3faf84e85e6d1ca478215d10ea76c2
treed2415669d2d91202405fa2ad56386c9c826412b1
parent7cc94a7252d8b57307b10fc36116e8d792d2ed60
btrfs: stripe_alloc: let the property accept a cache-less filesystem like the mount option does

The "stripe_alloc" filesystem property and the mount option are meant to
be two ways to turn on one policy, and they answer the same questions
about the filesystem -- except one.  btrfs_check_mountopts() refuses the
option only for space_cache=v1: the v1 cache inode is nodatacow and
preallocated, so a commit overwrites it in place, a sub-stripe write
into committed stripes that no csum would ever show.  The free space
tree and no cache at all are both fine, and nothing in the allocator
reads either.  btrfs_stripe_alloc_check_support(), which the property
calls, demanded the free space tree instead, so a filesystem mounted
with nospace_cache took the option but refused the property, and the
error it gave named a requirement the option does not have.

Refuse what the mount path refuses: the v1 cache, both the live option
and cache inodes still on disk from an earlier mount, which
btrfs_read_block_groups() already refuses for the option (the property
can arrive on a live filesystem, after that check ran).  The two paths
now agree, and bg-gate-test.sh's property cases hold them to it.

Assisted-by: Claude:claude-fable-5-1
fs/btrfs/block-group.c