Linux Btrfs filesystem development
 help / color / mirror / Atom feed
* [BUG] two raid consistency bugs
@ 2026-07-14 16:10 Zhang Boyang
  2026-07-14 16:10 ` [PATCH 1/2] fstests: btrfs/348: test ambiguous generation handling on raid1 profile Zhang Boyang
                   ` (2 more replies)
  0 siblings, 3 replies; 14+ messages in thread
From: Zhang Boyang @ 2026-07-14 16:10 UTC (permalink / raw)
  To: linux-btrfs; +Cc: David Sterba, Qu Wenruo, Filipe Manana

Hello btrfs devs,

I found two raid-related bugs in btrfs. Two test cases are provided.


BUG 1. fstests: btrfs/348: test ambiguous generation handling on raid1 profile

This test simulates a ambiguous generation which can be caused by, for
example, two successive power failures. Please note this is not related
to degraded mounts or nodatacow.

This bug may affect several raid levels, take raid1 (say disk A and B)
as an example:

At first power failure during transaction N, metadata trees of
generation N are written to disk A, but super is not committed. Nothing
is written to disk B.

At second power failure during a different transaction N, nothing is
written to disk A, but metadata trees and super is committed to disk B.

This creates a ambiguous generation N in two disks. Currently btrfs
can't detect this, and can lead to severe damages. 

I'd like to discuss possible solutions:

1) Turn btrfs metadata trees into merkle trees

This is the most CoW flavor solution. With a strong checksum algorithm,
merkle tree can gurantee ambiguous is detected and fixed.  However it is
difficult to implement because metadata checksumming is done at bio time
(not at tree manipulation time), also on-disk format is changed. 

2) A write-intent bitmap

This is the traditional solution to raid consistency problem. This can
also helps resync nodatacow data. However it seems there is an anandoned
series of write-intent patches in btrfs mailing list.

3) Generation redzone

Introduce a generation redzone value to superblock, which is updated at
mount time, for example:

1st mount: generation=N redzone=N   -> next generation id is N+1
2nd mount: generation=N redzone=N+1 -> next generation id is N+2
3rd mount: generation=N redzone=N+2 -> next generation id is N+3

However it seems there can be infinte TRANS_STATE_UNBLOCKED
transactions, so it's hard to decide how may delta should we add to
redzone value to get next generation id. 

Also, this redzone value is not applicable to tree-log, so BUG 2 (see
below) can't be solved.

4) Dirty workaround

Pin metadata to a dedicated device (which can be LVM raid1) and ask user
to run single metadata profile. This is too dirty and should not used.


BUG 2. fstests: btrfs/349: test if latest tree-log is choosen at mount time on raid1 profile

This test simulate a scenario that tree-log only exists in secondary
device, and test if latest tree-log is choosen at mount time. Currently,
the tree-log in the device with lowest devid is choosen. So fsync'ed
data may loss if tree-log only exists in secondary device.

A proposed draft fix is available at:

https://lore.kernel.org/linux-btrfs/20260605102607.23786-1-zhangboyang.id@gmail.com/

However, this draft fix also suffers from the above ambiguous generation
problem.


Zhang Boyang



^ permalink raw reply	[flat|nested] 14+ messages in thread
end of thread, other threads:[~2026-07-15 13:12 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-07-14 16:10 [BUG] two raid consistency bugs Zhang Boyang
2026-07-14 16:10 ` [PATCH 1/2] fstests: btrfs/348: test ambiguous generation handling on raid1 profile Zhang Boyang
2026-07-14 16:10 ` [PATCH 2/2] fstests: btrfs/349: test if latest tree-log is choosen at mount time " Zhang Boyang
2026-07-14 21:40 ` [BUG] two raid consistency bugs Qu Wenruo
2026-07-15  5:46   ` Zhang Boyang
2026-07-15  6:10     ` Qu Wenruo
2026-07-15  7:38       ` Zhang Boyang
2026-07-15  8:36         ` Qu Wenruo
2026-07-15  9:25           ` Zhang Boyang
2026-07-15  9:44             ` Qu Wenruo
2026-07-15 10:07               ` Zhang Boyang
2026-07-15 10:11                 ` Qu Wenruo
2026-07-15 10:41                   ` Zhang Boyang
2026-07-15 13:11                   ` Alan Huang

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox