btrfs: stripe_alloc: drop the mount options, the property is the interface
stripe_alloc and stripe_alloc_allow_rmw were mount options and filesystem
properties both. Upstream will not take new mount options for this, and the
two interfaces have to be kept in step by hand -- a bug class this series has
already paid for twice, once when the property skipped the mixed-block-group
refusal the option made, and once when the two disagreed about a cache-less
filesystem.
Remove the options. Nothing is lost:
- btrfs_stripe_alloc_check_support(), which the property calls, already
refuses everything btrfs_check_mountopts() refused -- v1 space cache,
zoned, mixed block groups -- and one thing more, a v1 cache still present
on disk from an earlier mount. So the mount-time block was the weaker of
the two checks, not the stronger.
- The runtime state is untouched. BTRFS_MOUNT_STRIPE_ALLOC and
fs_info->stripe_rmw_opt stay; btrfs_enable_stripe_alloc() and the
stripe_alloc_allow_rmw property already own them, and every
btrfs_test_opt(fs_info, STRIPE_ALLOC) in the allocator is unchanged.
- btrfs_parse_stripe_rmw() and btrfs_show_stripe_rmw() keep their other
callers in props.c and block-group.c.
The mount-time report collapses to one source, so it no longer has to say
which of two things turned the policy on, and btrfs_fill_super() no longer has
to sample the flag before open_ctree() to tell them apart. The remount path
loses its report with the option: a remount can no longer change the policy,
and the property announces its own changes.
Enabling the policy is now: mount, then
setfattr -n btrfs.stripe_alloc -v 1 /mnt
on the top-level root directory, which persists across mounts.
The "does not cover raid56 system chunks" warning moves from
btrfs_read_block_groups() to btrfs_enable_stripe_alloc(): block groups are
read before the root directory's properties apply, so with the option gone
the flag was always clear at the old call site and the warning could never
fire (bg-gate-test.sh caught it).
projects / linux / commit