From: David Vrabel <david.vrabel@citrix.com>
To: Bob Liu <bob.liu@oracle.com>, xen-devel@lists.xen.org
Cc: jgross@suse.com, Ian.Jackson@citrix.com, Paul.Durrant@citrix.com,
roger.pau@citrix.com
Subject: Re: [RFC PATCH] Data integrity extension support for xen-block
Date: Fri, 8 Apr 2016 15:16:50 +0100 [thread overview]
Message-ID: <5707BD52.7040901@citrix.com> (raw)
In-Reply-To: <1460023200-20255-1-git-send-email-bob.liu@oracle.com>
On 07/04/16 11:00, 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.
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.
David
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-04-08 14:16 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 [this message]
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
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=5707BD52.7040901@citrix.com \
--to=david.vrabel@citrix.com \
--cc=Ian.Jackson@citrix.com \
--cc=Paul.Durrant@citrix.com \
--cc=bob.liu@oracle.com \
--cc=jgross@suse.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 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.