xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Bob Liu <bob.liu@oracle.com>
To: xen-devel@lists.xen.org
Cc: jgross@suse.com, Bob Liu <bob.liu@oracle.com>,
	Paul.Durrant@citrix.com, david.vrabel@citrix.com,
	Ian.Jackson@citrix.com, roger.pau@citrix.com
Subject: [RFC PATCH v2] Data integrity extension(DIX) support for xen-block
Date: Wed, 20 Apr 2016 15:26:09 +0800	[thread overview]
Message-ID: <1461137170-24787-1-git-send-email-bob.liu@oracle.com> (raw)

* What's data integrity extension(DIX) 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.
Both raw data and integrity metadata are mapped to two separate scatterlists.

* Issues when xen-block get involved.
xen-blkfront only transmits the raw data-segment scatterlist of each bio
while the integrity-metadata-segment scatterlist has been ignored.

* Proposal for transmitting integrity-metadata-segment scatterlist.
Adding an extra request following the normal data request, this extra request
contains integrity-metadata segments only.

The xen-blkback will reconstruct the new bio with recevied data and integrity
segments.

Signed-off-by: Bob Liu <bob.liu@oracle.com>
---
 xen/include/public/io/blkif.h |   19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/xen/include/public/io/blkif.h b/xen/include/public/io/blkif.h
index 99f0326..a0124b2 100644
--- a/xen/include/public/io/blkif.h
+++ b/xen/include/public/io/blkif.h
@@ -182,6 +182,15 @@
  *      backend driver paired with a LIFO queue in the frontend will
  *      allow us to have better performance in this scenario.
  *
+ * feature-data-integrity
+ *      Values:         0/1 (boolean)
+ *      Default Value:  0
+ *
+ *      A value of "1" indicates that the backend can process requests
+ *      containing the BLKIF_OP_DIX_FLAG request opcode.  Requests
+ *      with this flag means the following request is a special request which
+ *      only contains integrity-metadata segments of current request.
+ *
  *----------------------- Request Transport Parameters ------------------------
  *
  * max-ring-page-order
@@ -635,6 +644,16 @@
 #define BLKIF_OP_INDIRECT          6
 
 /*
+ * Recognized only if "feature-data-integrity" is present in backend xenbus info.
+ * A request with BLKIF_OP_DIX_FLAG indicates the following request is a special
+ * request which only contains integrity-metadata segments of current request.
+ *
+ * If a backend does not recognize BLKIF_OP_DIX_FLAG, it should *not* create the
+ * "feature-data-integrity" node!
+ */
+#define BLKIF_OP_DIX_FLAG (0x80)
+
+/*
  * Maximum scatter/gather segments per request.
  * This is carefully chosen so that sizeof(blkif_ring_t) <= PAGE_SIZE.
  * NB. This could be 12 if the ring indexes weren't stored in the same page.
-- 
1.7.10.4


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

             reply	other threads:[~2016-04-20  7:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-20  7:26 Bob Liu [this message]
2016-04-20  8:59 ` [RFC PATCH v2] Data integrity extension(DIX) support for xen-block David Vrabel
2016-04-20 12:08   ` Bob Liu
2016-04-20 13:49     ` David Vrabel

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=1461137170-24787-1-git-send-email-bob.liu@oracle.com \
    --to=bob.liu@oracle.com \
    --cc=Ian.Jackson@citrix.com \
    --cc=Paul.Durrant@citrix.com \
    --cc=david.vrabel@citrix.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 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).