Re: status of block-integrity
On Jan 6, 2014, at 8:36 PM, Darrick J. Wong darrick.w...@oracle.com wrote: On Fri, Jan 03, 2014 at 03:03:42PM -0500, Martin K. Petersen wrote: Hannes == Hannes Reinecke h...@suse.de writes: Hannes Personally, I doubt it's a good idea to kill it off, but a Hannes proper (userland) API for it has been a long time missing. Before we throw the baby out with the bath water, maybe Darrick can fill us in on the progress of the aio passthrough interface? I haven't made much progress on it -- I haven't seen any earnest demand for it. Last year Chuck Lever said that some NFS working group was looking defining an interface it... has there been any progress? It doesn't sound like there has been. You must be thinking of some other Chuck Lever ;-) What I promised to deliver was plumbing in the NFS protocol to support end-to-end data integrity. That's here: https://datatracker.ietf.org/doc/draft-cel-nfsv4-end2end-data-protection/ The issue of system call API is as sticky for NFS as it is for other e2e implementations. Without an API, other projects have been allowed to take up the time I would have spent on an NFS prototype. What's more, some of the fields in the T10 tag are meaningless for byte-stream: an application, for example, will know nothing of block addresses, since those are chosen by the underlying filesystem. NFS (or any byte stream e2e integrity API) will have to define a different protection envelope with perhaps different tag contents. But we do have a range of potential use cases for NFS: hypervisors that emulate block devices using NFS files, strong cryptographic data checksums, and of course the Oracle database. No real demand, as others have said. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [LSF/MM TOPIC][ATTEND] protection information and userspace
On Feb 6, 2013, at 3:24 PM, Darrick J. Wong darrick.w...@oracle.com wrote:
On Wed, Feb 06, 2013 at 01:51:22PM -0600, Ben Myers wrote:
Hi,
I'm interested in discussing how to pass protection information to and from
userspace. Maybe Martin could be enlisted for the discussion.
I read that some work has already been done in this area but have not been
able
to locate it. It looks like the bio-integrity code already makes it possible
to generate the t10-dif crc in the filesystem. It would be good to be able
to
get the guard and application tags back out to backup applications such as
xfsdump. Enabling other applications to generate their own tags in userspace
is also interesting.
This one's been on my list for a couple of years (and companies) too. A few
years ago Joel Becker had support for it in his sys_dio proposal (that hasn't
gone anywhere), and more recently I've theorized that we could add a magic
fcntl/ioctl to make the kernel recognize, say, the first iovec of a O_DIRECT
*{read,write}v call as the PI buffer, which I think is similar to how DIX gets
PI data to a disk. But it's not like I have any code to show for it.
I /think/ it's fairly straightforward to change the directio submit code to
find the userspace PI buffer and amend the block integrity code to attach our
own PI buffer. You'd still have to let the block layer set the sector #
field,
but afaik that won't affect the crc or the app tag.
I hear that the NFS guys want to propose some sort of protocol for
transmitting
PI data (across NFS), but I haven't seen anything concrete yet.
I'm writing a requirements document for the NFS protocol which I can discuss at
LSF. The use cases for NFS for now would be virtual disk devices (hypervisors)
or direct NFS access to storage from user space.
Like everyone else we are waiting for a magical VFS and user space API to
appear that can pass PI to and from storage.
Well, I hope I'll scrape together the time to hack together a PoC before
LSF...
on the other hand, I ran the discussion about PI userland interfaces at
LPC2011
and (shamefully) haven't done anything yet.
end rambling
--D
Regards,
Ben
--
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
