Re: Ideas to reuse filesystem's checksum to enhance dm-raid1/10/5/6?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux