]> git.hungrycats.org Git - linux/commit
btrfs: stripe_alloc: report read-modify-write of uncovered stripes
authorZygo Blaxell <ce3g8jdj@umail.furryterror.org>
Tue, 4 Aug 2026 19:51:54 +0000 (15:51 -0400)
committerZygo Blaxell <ce3g8jdj@umail.furryterror.org>
Fri, 18 Sep 2026 21:36:23 +0000 (17:36 -0400)
commit1f4f8667d2d765ec250913ef2a9e2c7535ae98d6
tree625ac95c0b1260dad08b08164ab2ab5ecfc2c33b
parentb4ccc8d8bc0363872656a8a43b8e5a1b1564674b
btrfs: stripe_alloc: report read-modify-write of uncovered stripes

The mount-time warning says which block groups stripe_alloc does not
cover.  It cannot say whether anything is actually landing there, and on
a filesystem with raid56 metadata that is the interesting question: every
sub-stripe write to an uncovered stripe is a write hole window, where
parity and data reach the disk separately and a crash in between leaves
the stripe unreconstructible.

Report it from the one place that knows the write is going out as a
read-modify-write rather than as a full or padded stripe.  Rate limited,
because a raid56-metadata filesystem does this continuously and the point
is to make the exposure visible rather than to fill the log, and paired
with a meta_rmw counter in the existing stripe_park_stats sysfs file so
the rate can be read off without grepping dmesg.

Silent when stripe_alloc is off: there the whole filesystem works this
way and the user has asked for nothing else.

Assisted-by: Claude:claude-fable-5
fs/btrfs/fs.h
fs/btrfs/raid56.c
fs/btrfs/sysfs.c