Re: [RFC PATCH] Data integrity extension support for xen-block

From: Bob Liu <bob.liu@oracle.com>
To: David Vrabel <david.vrabel@citrix.com>
Cc: jgross@suse.com, Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel@lists.xen.org, Paul.Durrant@citrix.com,
	roger.pau@citrix.com
Subject: Re: [RFC PATCH] Data integrity extension support for xen-block
Date: Mon, 11 Apr 2016 20:32:25 +0800	[thread overview]
Message-ID: <570B9959.9050800@oracle.com> (raw)
In-Reply-To: <5707C0F7.9050801@citrix.com>

On 04/08/2016 10:32 PM, David Vrabel wrote:
> On 08/04/16 15:20, Ian Jackson wrote:
>> David Vrabel writes ("Re: [RFC PATCH] Data integrity extension support for xen-block"):
>>> You need to read the relevant SCSI specification and find out what
>>> interfaces and behaviour the hardware has so you can specify compatible
>>> interfaces in blkif.
>>>
>>> My (brief) reading around this suggests that the integrity data has a
>>> specific format (a CRC of some form) and the integrity data written for
>>> sector S and retrieved verbatim when sector S is re-read.
>>
>> I think it's this:
>>
>> https://en.wikipedia.org/wiki/Data_Integrity_Field
>> https://www.kernel.org/doc/Documentation/block/data-integrity.txt
>>
>> In which case AFAICT the format is up to the guest (ie the operating
>> system or file system) and it's opaque to the host (the storage) -
>> unless the guest consents, of course.
> 
> I disagree, but I can't work out where to get the relevant T10 PI/DIF
> spec from to provide an authoritative link[1].  The DI metadata has as a
> set of well defined format, most of which include a 16-bit GUARD CRC, a
> 32 bit REFERENCE tag and 16 bit for user defined usage.
> 

Yes.

> The application cannot use all the bits for its own use since the
> hardware may check the GUARD and REFERENCE tags itself.
> 
> David
> 
> [0] Try: https://www.usenix.org/legacy/event/lsf07/tech/petersen.pdf
> 

And https://oss.oracle.com/projects/data-integrity/dist/documentation/dix.pdf

No matter the actual format of the Integrity Meta Data looks like, it can be mapped to a scatter-list by using:
blk_rq_map_integrity_sg(struct request_queue *q, struct bio *bio, struct scatterlist *sglist)
just like blk_rq_map_sg(struct request_queue *q, struct request *rq, struct scatterlist *sglist) for normal data.

The extra scatter-list can be seen as the interface, we just need to find a good way transmitting this extra scatter-list between blkfront and blkback.

-- 
Regards,
-Bob

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel