On Sat, 8 Jan 2022 19:52:59 +0000 Lukas Straub <lukasstraub2@xxxxxx> wrote: > CC'ing linux-raid mailing list, where md raid development happens. > dm-raid is just a different interface to md raid. > > On Fri, 7 Jan 2022 10:30:56 +0800 > Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote: > > > Hi, > > > > Recently I'm working on refactor btrfs raid56 (with long term objective > > to add proper journal to solve write-hole), and the coverage of current > > fstests for btrfs RAID56 is not that ideal. > > > > Is there any project testing dm/md RAID456 for things like > > re-silvering/write-hole problems? > > > > And how you dm guys do the tests for stacked RAID456? > > > > I really hope to learn some tricks from the existing, tried-and-true > > RAID456 implementations, and hopefully to solve the known write-hole > > bugs in btrfs. Just some thoughts: Besides the journal to mitigate the write-hole, md raid has another trick: The Partial Parity Log https://www.kernel.org/doc/html/latest/driver-api/md/raid5-ppl.html When a stripe is partially updated with new data, PPL ensures that the old data in the stripe will not be corrupted by the write-hole. The new data on the other hand is still affected by the write hole, but for btrfs that is no problem. But there is a even simpler solution for btrfs: It could just not touch stripes that already contain data. The big problem will be NOCOW files, since a write to an already allocated extent will necessarily touch a stripe with old data in it and the new data also needs to be protected from the write-hole. Regards, Lukas Straub > > Thanks, > > Qu > > > > > > -- > > dm-devel mailing list > > dm-devel@xxxxxxxxxx > > https://listman.redhat.com/mailman/listinfo/dm-devel > > > > > --
Attachment:
pgp0EhWi4cjGJ.pgp
Description: OpenPGP digital signature
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
