linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
	Chuck Lever <chuck.lever@oracle.com>,
	lsf-pc@lists.linux-foundation.org,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
	linux-scsi@vger.kernel.org,
	Sven Breuner <sven.breuner@itwm.fraunhofer.de>
Subject: Re: [LSF/MM TOPIC] end-to-end data and metadata corruption detection
Date: Thu, 26 Jan 2012 17:21:44 -0600	[thread overview]
Message-ID: <1327620104.6151.23.camel@dabdike.int.hansenpartnership.com> (raw)
In-Reply-To: <4F217F0C.6030105@itwm.fraunhofer.de>

On Thu, 2012-01-26 at 17:27 +0100, Bernd Schubert wrote:
> On 01/26/2012 03:53 PM, Martin K. Petersen wrote:
> >>>>>> "Bernd" == Bernd Schubert<bernd.schubert@itwm.fraunhofer.de>  writes:
> >
> > Bernd>  We from the Fraunhofer FhGFS team would like to also see the T10
> > Bernd>  DIF/DIX API exposed to user space, so that we could make use of
> > Bernd>  it for our FhGFS file system.  And I think this feature is not
> > Bernd>  only useful for file systems, but in general, scientific
> > Bernd>  applications, databases, etc also would benefit from insurance of
> > Bernd>  data integrity.
> >
> > I'm attending a SNIA meeting today to discuss a (cross-OS) data
> > integrity aware API. We'll see what comes out of that.
> >
> > With the Linux hat on I'm still mainly interested in pursuing the
> > sys_dio interface Joel and I proposed last year. We have good experience
> > with that I/O model and it suits applications that want to interact with
> > the protection information well. libaio is also on my list.
> >
> > But obviously any help and input is appreciated...
> >
> 
> I guess you are referring to the interface described here
> 
> http://www.spinics.net/lists/linux-mm/msg14512.html
> 
> Hmm, direct IO would mean we could not use the page cache. As we are 
> using it, that would not really suit us. libaio then might be another 
> option then.

Are you really sure you want protection information and the page cache?
The reason for using DIO is that no-one could really think of a valid
page cache based use case.  What most applications using protection
information want is to say: This is my data and this is the integrity
verification, send it down and assure me you wrote it correctly.  If you
go via the page cache, we have all sorts of problems, like our
granularity is a page (not a block) so you'd have to guarantee to write
a page at a time (a mechanism for combining subpage units of protection
information sounds like a nightmare).  The write becomes mark page dirty
and wait for the system to flush it, and we can update the page in the
meantime.  How do we update the page and its protection information
atomically.  What happens if the page gets updated but no protection
information is supplied and so on ...  The can of worms just gets more
squirmy.  Doing DIO only avoids all of this.

James



  reply	other threads:[~2012-01-26 23:21 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
2012-01-26 12:31 ` Bernd Schubert
2012-01-26 14:53   ` Martin K. Petersen
2012-01-26 16:27     ` Bernd Schubert
2012-01-26 23:21       ` James Bottomley [this message]
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
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
2012-02-02  9:04                         ` Bernd Schubert
2012-02-02 19:26                           ` Andrea Arcangeli
2012-02-02 19:46                             ` Andreas Dilger
2012-02-02 22:52                             ` Bernd Schubert
2012-02-01 18:15                 ` Martin K. Petersen
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=1327620104.6151.23.camel@dabdike.int.hansenpartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=bernd.schubert@itwm.fraunhofer.de \
    --cc=chuck.lever@oracle.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).