public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Jens Axboe <axboe@kernel.dk>
Cc: Christoph Hellwig <hch@lst.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Daniel Stodden <daniel.stodden@citrix.com>,
	Xen-devel <xen-devel@lists.xensource.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Subject: [PATCH 0/4] FLUSH/FUA updates for Xen blkfront
Date: Tue,  2 Nov 2010 12:20:43 -0400	[thread overview]
Message-ID: <cover.1288714384.git.jeremy.fitzhardinge@citrix.com> (raw)

From: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>

Update the Xen blockfront driver to deal with the block layer's cache
flush and FUA operations.

The only primitive we have for implementing these is
BLKIF_OP_WRITE_BARRIER, which is a fully ordered write operation.
This is much stronger than a simple cache flush which Linux requires,
but it will do the job.

It can also implement FUA, since it will guarantee that the data is
written to stable storage when it completes - however it also
implements full ordering, which makes it equivalent to a FLUSH+FUA.

Unfortunately it appears that the actual Xen backend implementation
will fail an empty BLKIF_OP_WRITE_BARRIER operation.  If that happens,
disable use of WRITE_BARRIER.  (Daniel, I don't know if this is
deliberate or not; I couldn't see where the error was coming from).

Jeremy Fitzhardinge (4):
  xen/blkfront: map REQ_FLUSH into a full barrier
  xen/blkfront: change blk_shadow.request to proper pointer
  xen/blkfront: Implement FUA with BLKIF_OP_WRITE_BARRIER
  xen/blkfront: cope with backend that fail empty
    BLKIF_OP_WRITE_BARRIER requests

 drivers/block/xen-blkfront.c |   53 +++++++++++++++++++++++------------------
 1 files changed, 30 insertions(+), 23 deletions(-)

-- 
1.7.2.3


             reply	other threads:[~2010-11-02 16:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-02 16:20 Jeremy Fitzhardinge [this message]
2010-11-02 16:20 ` [PATCH 1/4] xen/blkfront: map REQ_FLUSH into a full barrier Jeremy Fitzhardinge
2010-11-02 16:20 ` [PATCH 2/4] xen/blkfront: change blk_shadow.request to proper pointer Jeremy Fitzhardinge
2010-11-02 16:20 ` [PATCH 3/4] xen/blkfront: Implement FUA with BLKIF_OP_WRITE_BARRIER Jeremy Fitzhardinge
2010-11-02 16:20 ` [PATCH 4/4] xen/blkfront: cope with backend that fail empty BLKIF_OP_WRITE_BARRIER requests Jeremy Fitzhardinge
2010-11-02 16:54   ` Christoph Hellwig

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=cover.1288714384.git.jeremy.fitzhardinge@citrix.com \
    --to=jeremy@goop.org \
    --cc=axboe@kernel.dk \
    --cc=daniel.stodden@citrix.com \
    --cc=hch@lst.de \
    --cc=jeremy.fitzhardinge@citrix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xen-devel@lists.xensource.com \
    /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