From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Matthew Wilcox <matthew@wil.cx>
Cc: Hannes Reinecke <hare@suse.de>,
Ric Wheeler <ricwheeler@gmail.com>,
"Martin K. Petersen" <mkp@mkp.net>,
Christoph Hellwig <hch@infradead.org>,
Jens Axboe <axboe@kernel.dk>,
linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org,
Linux FS Devel <linux-fsdevel@vger.kernel.org>
Subject: Re: status of block-integrity
Date: Wed, 08 Jan 2014 08:05:10 +0800 [thread overview]
Message-ID: <1389139510.2064.22.camel@dabdike.pnp.gw> (raw)
In-Reply-To: <20140107233410.GA1263@parisc-linux.org>
On Tue, 2014-01-07 at 16:34 -0700, Matthew Wilcox wrote:
> On Tue, Jan 07, 2014 at 02:33:10PM +0100, Hannes Reinecke wrote:
> > I would indeed like to have a discussion at LSF about the future of
> > DIX. DIF is not an issue, as most HBAs support it already and we
> > actually need it for proper connectivity.
> >
> > DIX, OTOH, has been left dormant since time immemorial, with the
> > only known (supposed) user being Oracle.
> > (I actually talked to the DB/2 folks about it, and the response
> > was a polite feigned interest ...)
>
> I think there's a terminology confusion here; you seem to be using DIX
> to mean the TCP CRC and DIF to mean T10DIF. I've seen other people use
> DIX to mean separate SGLs for metadata and DIF to mean interleaved data.
> Can you confirm which thing you mean here?
No, I think you're confusing algorithms with protocols. DIF and DIX are
two names for protection envelopes. DIF verifies integrity from the HBA
to the device surface. DIX verifies integrity from an application to
the HBA. Both DIF and DIX have pluggable checksum algorithms (and, in
theory, as long as the HBA does the conversion, they don't have to use
the same one, although the confusion over protection types and
algorithms is so dense already that the only way not to go insane is to
use the same end to end one). Oracle has the best data sources to
explain this, including Martin's slides:
https://oss.oracle.com/projects/data-integrity/documentation/
The specific problem is that there's no defined interface for any
application to use DIX easily because it has to supply additional
protection information when it reads or writes data and there's no
agreed way to extend read/write to do this and, as Martin has said,
thinging about trying to do this with mmap leads to a "bonghit bonanza".
So, the question is do we need to bother with DIX at all? No filesystem
uses it and there seems to be weak user demand at best. We could just
strip DIX, losing the protection envelope from the application to the
HBA but keeping DIF, which is the protection envelope from the HBA to
the device.
James
next prev parent reply other threads:[~2014-01-08 0:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20131222192128.GA28532@infradead.org>
[not found] ` <yq11u134rmt.fsf@sermon.lab.mkp.net>
2014-01-07 8:28 ` status of block-integrity Ric Wheeler
2014-01-07 13:33 ` Hannes Reinecke
2014-01-07 23:34 ` Matthew Wilcox
2014-01-08 0:05 ` James Bottomley [this message]
2014-01-08 15:43 ` 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=1389139510.2064.22.camel@dabdike.pnp.gw \
--to=james.bottomley@hansenpartnership.com \
--cc=axboe@kernel.dk \
--cc=hare@suse.de \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=mkp@mkp.net \
--cc=ricwheeler@gmail.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).