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
next prev parent 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.