On 2017年11月17日 06:32, Chris Murphy wrote: > On Thu, Nov 16, 2017 at 3:04 AM, Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote: > >> For example, if we use the following device mapper layout: >> >> FS (can be any fs with metadata csum) >> | >> dm-integrity >> | >> dm-raid1 >> / \ >> disk1 disk2 > > > You would instead do dm-integrity per physical device, then make the > two dm-integrity devices, members of md raid1 array. Now when > integrity fails, basically it's UNC error to raid1 which then gets the > copy from the other device. Yep, dm-integrity under raid1 makes much more sense here. Although, double the CPU usage for each device added in. > > But what you're getting at, that dm-integrity is more complicated, is > true, in that it's at least partly COW based in order to get the > atomic write guarantee needed to ensure data blocks and csums are > always in sync, and reliable. But this also applies to the entire file > system. The READ bio concept you're proposing leverages pretty much > already existing code, has no write performance penalty or complexity > at all, but does miss data for file systems that don't csum data > blocks. That's true, since currently only Btrfs supports data csum. And to make filesystem to support data csum, it needs CoW support while only XFS and Btrfs supports CoW yet. > It's good the file system can stay alive, but data is the much > bigger target in terms of percent space on the physical media, It's also true. (Although working on btrfs sometimes makes me care more about safe metadata) Thanks, Qu > and > more likely to be corrupt or go missing due to media defect or > whatever. It's still possible for silent data corruption to happen. > > > > >> I just want to make device-mapper raid able to handle such case too. >> Especially when most fs supports checksum for their metadata. > > XFS by default does metadata csums. But ext4 doesn't use it for either > metadata or the journal by default still, it is still optional. So for > now it mainly benefits XFS. > >
Attachment:
signature.asc
Description: OpenPGP digital signature
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
