From: "Pasi Kärkkäinen" <pasik@iki.fi>
To: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
Cc: Qu Wenruo <quwenruo.btrfs@gmx.com>,
Zdenek Kabelac <zkabelac@redhat.com>,
Nikolay Borisov <nborisov@suse.com>,
linux-block@vger.kernel.org, dm-devel@redhat.com,
linux-fsdevel@vger.kernel.org,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: Ideas to reuse filesystem's checksum to enhance dm-raid1/10/5/6?
Date: Thu, 16 Nov 2017 23:05:34 +0200 [thread overview]
Message-ID: <20171116210534.GK20756@reaktio.net> (raw)
In-Reply-To: <391774c5-81f8-cdda-3dbe-4d3d1c2fa3d7@gmail.com>
On Thu, Nov 16, 2017 at 11:47:45AM -0500, Austin S. Hemmelgarn wrote:
> >
> >At least btrfs can take the advantage of the simplicity of separate layers.
> >
> >And other filesystem can get a little higher chance to recover its
> >metadata if built on dm-raid.
> Again, just put dm-integrity below dm-raid. The other filesystems primarily
> have metadata checksums to catch data corruption, not repair it, and I
> severely doubt that you will manage to convince developers to add support in
> their filesystem (especially XFS) because:
> 1. It's a layering violation (yes, I know BTRFS is too, but that's a bit
> less of an issue because it's a completely self-contained layering
> violation, while this isn't).
> 2. There's no precedent in hardware (I challenge you to find a block device
> that lets you respond to a read completing with 'Hey, this data is bogus,
> give me the real data!').
>
Isn't this what T10 DIF/DIX (Data Integrity Fields / Data Integrity Extenstions) allows.. using checksums all the way from userspace applications to the disks in the storage backend, with checksum verification at all points in between?
Does require compatible hardware/firmware/kernel/drivers/apps though.. so not really a generic solution.
-- Pasi
> 3. You can get the same net effect with a higher guarantee of security using
> dm-integrity.
> >
> >Thanks,
> >Qu
> >
> >>
> >>You are also possibly missing feature of dm-interity - it's not just
> >>giving you 'checksum' - it also makes you sure - device has proper
> >>content - you can't just 'replace block' even with proper checksum for a
> >>block somewhere in the middle of you device... and when joined with
> >>crypto - it makes it way more secure...
> >>
> >>Regards
> >>
> >>Zdenek
> >
>
next prev parent reply other threads:[~2017-11-16 21:11 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-16 2:18 Ideas to reuse filesystem's checksum to enhance dm-raid1/10/5/6? Qu Wenruo
2017-11-16 6:54 ` Nikolay Borisov
2017-11-16 7:38 ` Qu Wenruo
2017-11-16 7:42 ` Nikolay Borisov
2017-11-16 8:08 ` Qu Wenruo
2017-11-16 9:43 ` Zdenek Kabelac
2017-11-16 10:04 ` Qu Wenruo
2017-11-16 12:33 ` Zdenek Kabelac
2017-11-16 12:41 ` Austin S. Hemmelgarn
2017-11-16 14:06 ` Qu Wenruo
2017-11-16 16:47 ` Austin S. Hemmelgarn
2017-11-16 21:05 ` Pasi Kärkkäinen [this message]
2017-11-17 1:30 ` Qu Wenruo
2017-11-17 12:22 ` Austin S. Hemmelgarn
2017-11-16 22:32 ` Chris Murphy
2017-11-17 1:22 ` Qu Wenruo
2017-11-17 1:54 ` Chris Murphy
2017-11-17 1:55 ` Chris Murphy
2017-11-21 2:53 ` [dm-devel] " Theodore Ts'o
2017-11-17 1:26 ` Andreas Dilger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171116210534.GK20756@reaktio.net \
--to=pasik@iki.fi \
--cc=ahferroin7@gmail.com \
--cc=dm-devel@redhat.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=nborisov@suse.com \
--cc=quwenruo.btrfs@gmx.com \
--cc=zkabelac@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).