]> 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>
Wed, 16 Sep 2026 21:40:02 +0000 (17:40 -0400)
commitfac1ef7207bab04f4160ae0aa4c64f29aece7bf5
tree6d93ab282ca12d00ce8c50894c4447fb15bf4be8
parent4a28fa64df5cb3531c14ce77bbe1058d000f8558
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