All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: 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 13:31:54 +0100	[thread overview]
Message-ID: <4F2147BA.6030607@itwm.fraunhofer.de> (raw)
In-Reply-To: <38C050B3-2AAD-4767-9A25-02C33627E427@oracle.com>

On 01/17/2012 09:15 PM, Chuck Lever wrote:
> Hi-
>
> I know there is some work on ext4 regarding metadata corruption
> detection; btrfs also has some corruption detection facilities.  The
> IETF NFS working group is considering the addition of corruption
> detection to the next NFSv4 minor version.  T10 has introduced
> DIF/DIX.
>
> I'm probably ignorant of the current state of implementation in
> Linux, but I'm interested in understanding common ground among local
> file systems, block storage, and network file systems.  Example
> questions include:  Do we need standardized APIs for block device
> corruption detection?  How much of T10 DIF/DIX should NFS support?
> What are the drivers for this feature (broad use cases)?
>

Other network file systems such as Lustre already use their own network 
data checksums. As far as I know Lustre plans (planned?) to use 
underlying ZFS checksums also for network transfers, so real 
client-to-disk (end-to-end) checksums. Using T10 DIF/DIX might be on 
their todo list.

We from the Fraunhofer FhGFS team would like to also see the T10 DIF/DIX 
API exposed to user space, so that we could make use of it for our FhGFS 
file system.
And I think this feature is not only useful for file systems, but in 
general, scientific applications, databases, etc also would benefit from 
insurance of data integrity.


Cheers,
Bernd


--
Bernd Schubert
Fraunhofer ITWM

WARNING: multiple messages have this Message-ID (diff)
From: Bernd Schubert <bernd.schubert-mPn0NPGs4xGatNDF+KUbs4QuADTiUCJX@public.gmane.org>
To: Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Cc: lsf-pc-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	linux-fsdevel
	<linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Linux NFS Mailing List
	<linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Sven Breuner
	<sven.breuner-mPn0NPGs4xGatNDF+KUbs4QuADTiUCJX@public.gmane.org>
Subject: Re: [LSF/MM TOPIC] end-to-end data and metadata corruption detection
Date: Thu, 26 Jan 2012 13:31:54 +0100	[thread overview]
Message-ID: <4F2147BA.6030607@itwm.fraunhofer.de> (raw)
In-Reply-To: <38C050B3-2AAD-4767-9A25-02C33627E427-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>

On 01/17/2012 09:15 PM, Chuck Lever wrote:
> Hi-
>
> I know there is some work on ext4 regarding metadata corruption
> detection; btrfs also has some corruption detection facilities.  The
> IETF NFS working group is considering the addition of corruption
> detection to the next NFSv4 minor version.  T10 has introduced
> DIF/DIX.
>
> I'm probably ignorant of the current state of implementation in
> Linux, but I'm interested in understanding common ground among local
> file systems, block storage, and network file systems.  Example
> questions include:  Do we need standardized APIs for block device
> corruption detection?  How much of T10 DIF/DIX should NFS support?
> What are the drivers for this feature (broad use cases)?
>

Other network file systems such as Lustre already use their own network 
data checksums. As far as I know Lustre plans (planned?) to use 
underlying ZFS checksums also for network transfers, so real 
client-to-disk (end-to-end) checksums. Using T10 DIF/DIX might be on 
their todo list.

We from the Fraunhofer FhGFS team would like to also see the T10 DIF/DIX 
API exposed to user space, so that we could make use of it for our FhGFS 
file system.
And I think this feature is not only useful for file systems, but in 
general, scientific applications, databases, etc also would benefit from 
insurance of data integrity.


Cheers,
Bernd


--
Bernd Schubert
Fraunhofer ITWM
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2012-01-26 12:32 UTC|newest]

Thread overview: 37+ 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-17 20:15 ` Chuck Lever
2012-01-26 12:31 ` Bernd Schubert [this message]
2012-01-26 12:31   ` Bernd Schubert
2012-01-26 14:53   ` Martin K. Petersen
2012-01-26 14:53     ` Martin K. Petersen
2012-01-26 16:27     ` Bernd Schubert
2012-01-26 16:27       ` Bernd Schubert
2012-01-26 23:21       ` James Bottomley
2012-01-31 19:16         ` Bernd Schubert
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: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 19:46                               ` Andreas Dilger
2012-02-02 22:52                             ` Bernd Schubert
2012-02-02 22:52                               ` Bernd Schubert
2012-02-01 18:15                 ` Martin K. Petersen
2012-02-01 23:03                   ` Boaz Harrosh
2012-02-01 23:03                     ` Boaz Harrosh
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-31  2:22         ` Martin K. Petersen
2012-01-26 15:36 ` 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=4F2147BA.6030607@itwm.fraunhofer.de \
    --to=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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.