From: Andrea Arcangeli <aarcange@redhat.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: Bernd Schubert <bernd.schubert@fastmail.fm>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
linux-scsi@vger.kernel.org,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Chuck Lever <chuck.lever@oracle.com>,
Sven Breuner <sven.breuner@itwm.fraunhofer.de>,
Gregory Farnum <gregory.farnum@dreamhost.com>,
lsf-pc@lists.linux-foundation.org,
Chris Mason <chris.mason@oracle.com>
Subject: Re: [Lsf-pc] [LSF/MM TOPIC] end-to-end data and metadata corruption detection
Date: Wed, 1 Feb 2012 19:30:54 +0100 [thread overview]
Message-ID: <20120201183054.GM31817@redhat.com> (raw)
In-Reply-To: <1328120165.2768.39.camel@dabdike.int.hansenpartnership.com>
On Wed, Feb 01, 2012 at 12:16:05PM -0600, James Bottomley wrote:
> supplying protection information to user space isn't about the
> application checking what's on disk .. there's automatic verification in
> the chain to do that (both the HBA and the disk will check the
> protection information on entry/exit and transfer). Supplying
> protection information to userspace is about checking nothing went wrong
> in the handoff between the end of the DIF stack and the application.
Not sure if I got this right, but keeping protection information for
in-ram pagecache and exposing it to userland somehow, to me sounds a
bit of overkill as a concept. Then you should want that for anonymous
memory too. If you copy the pagecache to a malloc()ed buffer and
verify pagecache was consistent, but then the buffer is corrupt by
hardware bitflip or software bug, then what's the point. Besides if
this is getting exposed to userland and it's not hidden in the kernel
(FS/Storage layers), userland could code its own verification logic
without much added complexity. With CRC in hardware on the CPU it
doesn't sound like a big cost to do it fully in userland and then you
could run it on anonymous memory too if you need and not be dependent
on hardware or filesystem details (well other than a a cpuid check at
startup).
next prev parent reply other threads:[~2012-02-01 19:15 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-17 20:15 [LSF/MM TOPIC] end-to-end data and metadata corruption detection Chuck Lever
[not found] ` <38C050B3-2AAD-4767-9A25-02C33627E427-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2012-01-26 12:31 ` Bernd Schubert
[not found] ` <4F2147BA.6030607-mPn0NPGs4xGatNDF+KUbs4QuADTiUCJX@public.gmane.org>
2012-01-26 14:53 ` Martin K. Petersen
[not found] ` <yq1k44e1pn6.fsf-+q57XtR/GgMb6DWv4sQWN6xOck334EZe@public.gmane.org>
2012-01-26 16:27 ` Bernd Schubert
2012-01-26 23:21 ` James Bottomley
[not found] ` <1327620104.6151.23.camel-sFMDBYUN5F8GjUHQrlYNx2Wm91YjaHnnhRte9Li2A+AAvxtiuMwx3w@public.gmane.org>
2012-01-31 19:16 ` Bernd Schubert
2012-01-31 19:21 ` Chuck Lever
2012-01-31 20:04 ` Martin K. Petersen
2012-01-31 2:10 ` Martin K. Petersen
2012-01-31 19:22 ` Bernd Schubert
2012-01-31 19:28 ` Gregory Farnum
2012-02-01 16:45 ` [Lsf-pc] " Chris Mason
2012-02-01 16:52 ` James Bottomley
[not found] ` <1328115175.2768.11.camel-sFMDBYUN5F8GjUHQrlYNx2Wm91YjaHnnhRte9Li2A+AAvxtiuMwx3w@public.gmane.org>
2012-02-01 17:41 ` Chris Mason
2012-02-01 17:59 ` Bernd Schubert
2012-02-01 18:16 ` James Bottomley
2012-02-01 18:30 ` Andrea Arcangeli [this message]
2012-02-02 9:04 ` Bernd Schubert
2012-02-02 19:26 ` Andrea Arcangeli
[not found] ` <20120202192643.GC5873-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2012-02-02 19:46 ` Andreas Dilger
2012-02-02 22:52 ` Bernd Schubert
2012-02-01 18:15 ` Martin K. Petersen
[not found] ` <yq1d39ys9n1.fsf-+q57XtR/GgMb6DWv4sQWN6xOck334EZe@public.gmane.org>
2012-02-01 23:03 ` Boaz Harrosh
[not found] ` <DE0353DF-83EA-480E-9C42-1EE760D6EE41@dilger.ca>
2012-01-31 2:22 ` Martin K. Petersen
2012-01-26 15:36 ` Martin K. Petersen
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=20120201183054.GM31817@redhat.com \
--to=aarcange@redhat.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=bernd.schubert@fastmail.fm \
--cc=bernd.schubert@itwm.fraunhofer.de \
--cc=chris.mason@oracle.com \
--cc=chuck.lever@oracle.com \
--cc=gregory.farnum@dreamhost.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=martin.petersen@oracle.com \
--cc=sven.breuner@itwm.fraunhofer.de \
/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).