From: Juergen Gross <jgross@suse.com>
To: Bob Liu <bob.liu@oracle.com>
Cc: xen-devel@lists.xen.org, Paul.Durrant@citrix.com,
david.vrabel@citrix.com, Ian.Jackson@citrix.com,
roger.pau@citrix.com
Subject: Re: [RFC PATCH] Data integrity extension support for xen-block
Date: Wed, 13 Apr 2016 16:43:47 +0200 [thread overview]
Message-ID: <570E5B23.9090908@suse.com> (raw)
In-Reply-To: <570E39F2.2010904@oracle.com>
On 13/04/16 14:22, Bob Liu wrote:
>
> On 04/07/2016 06:00 PM, Bob Liu wrote:
>> * What's data integrity extension and why?
>> Modern filesystems feature checksumming of data and metadata to protect against
>> data corruption. However, the detection of the corruption is done at read time
>> which could potentially be months after the data was written. At that point the
>> original data that the application tried to write is most likely lost.
>>
>> The solution in Linux is the data integrity framework which enables protection
>> information to be pinned to I/Os and sent to/received from controllers that
>> support it. struct bio has been extended with a pointer to a struct bip which
>> in turn contains the integrity metadata. The bip is essentially a trimmed down
>> bio with a bio_vec and some housekeeping.
>>
>> * Issues when xen-block get involved.
>> xen-blkfront only transmits the normal data of struct bio while the integrity
>> metadata buffer(struct bio_integrity_payload in each bio) is ignored.
>>
>> * Proposal of transmitting bio integrity payload.
>> Adding an extra request following the normal data request, this extra request
>> contains the integrity payload.
>> The xen-blkback will reconstruct an new bio with both received normal data and
>> integrity metadata.
>>
>> Welcome any better ideas, thank you!
>>
>
> A simpler possible solution:
>
> bob@boliuliu:~/xen$ git diff xen/include/public/io/blkif.h
> diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h
> index 3d8d39f..34581a5 100644
> --- a/xen/include/public/io/blkif.h
> +++ b/xen/include/public/io/blkif.h
> @@ -689,6 +689,11 @@ struct blkif_request_segment {
> struct blkif_request {
> uint8_t operation; /* BLKIF_OP_??? */
> uint8_t nr_segments; /* number of segments */
> + /*
> + * Recording how many segments are data integrity segments.
> + * raw data_segments + dix_segments = nr_segments
> + */
> + uint8_t dix_segments;
> blkif_vdev_t handle; /* only for read/write requests */
> uint64_t id; /* private guest value, echoed in resp */
> blkif_sector_t sector_number;/* start sector idx on disk (r/w only) */
> @@ -715,6 +720,11 @@ struct blkif_request_indirect {
> uint8_t operation; /* BLKIF_OP_INDIRECT */
> uint8_t indirect_op; /* BLKIF_OP_{READ/WRITE} */
> uint16_t nr_segments; /* number of segments */
> + /*
> + * Recording how many segments are data integrity segments.
> + * raw data_segments + dix_segments = nr_segments
> + */
> + uint16_t dix_segments;
> uint64_t id; /* private guest value, echoed in resp */
> blkif_sector_t sector_number;/* start sector idx on disk (r/w only) */
> blkif_vdev_t handle; /* same as for read/write requests */
>
Without having checked whether there were padding holes where you
introduced the new elements: this looks much better. As Ian already
pointed out: you should mention somewhere what the new segments are
containing (data layout description, possibly just a reference to a
hardware spec?).
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
prev parent reply other threads:[~2016-04-13 14:43 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-07 10:00 [RFC PATCH] Data integrity extension support for xen-block Bob Liu
2016-04-07 15:32 ` Ian Jackson
2016-04-07 15:55 ` Juergen Gross
2016-04-08 1:24 ` Bob Liu
2016-04-08 4:04 ` Juergen Gross
2016-04-08 9:44 ` Roger Pau Monné
2016-04-08 10:13 ` Bob Liu
2016-04-08 13:42 ` Ian Jackson
2016-04-11 15:04 ` Konrad Rzeszutek Wilk
2016-04-08 14:16 ` David Vrabel
2016-04-08 14:20 ` Ian Jackson
2016-04-08 14:32 ` David Vrabel
2016-04-11 12:32 ` Bob Liu
2016-04-13 12:22 ` Bob Liu
2016-04-13 13:19 ` Ian Jackson
2016-04-13 14:43 ` Juergen Gross [this message]
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=570E5B23.9090908@suse.com \
--to=jgross@suse.com \
--cc=Ian.Jackson@citrix.com \
--cc=Paul.Durrant@citrix.com \
--cc=bob.liu@oracle.com \
--cc=david.vrabel@citrix.com \
--cc=roger.pau@citrix.com \
--cc=xen-devel@lists.xen.org \
/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).