All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Alex Bligh <alex@alex.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, nbd-general@lists.sf.net,
	Paul Clements <Paul.Clements@steeleye.com>
Subject: Re: [PATCH 1/3] nbd: support FLUSH requests
Date: Wed, 13 Feb 2013 17:02:10 +0100	[thread overview]
Message-ID: <511BB902.3080302@redhat.com> (raw)
In-Reply-To: <3EDEF735-9A67-439E-BA65-089C6AAFD1BF@alex.org.uk>

Il 13/02/2013 16:55, Alex Bligh ha scritto:
>> > But as far as I can test with free servers, the FUA bits have no
>> > advantage over flush.  Also, I wasn't sure if SEND_FUA without
>> > SEND_FLUSH is valid, and if so how to handle this combination (treat it
>> > as writethrough and add FUA to all requests? warn and do nothing?).
> On the main opensource nbd client, the following applies:
> 
> What REQ_FUA does is an fdatasync() after the write. Code extract and
> comments below from Christoph Hellwig.
> 
> What REQ_FLUSH does is to do an fsync().
> 
> The way I read Christoph's comment, provided the linux block layer always
> issues a REQ_FLUSH before a REQ_FUA, there is not performance problem.
> 
> However, a REQ_FUA is going to do a f(data)?sync AFTER the write, whereas
> the preceding REQ_FLUSH is going to an fsync() BEFORE the write. It seems
> to me that either the FUA and FLUSH semantics are therefore different
> (and we need FUA), or that Christoph's comment is wrong and that you
> are guaranteed a REQ_FLUSH *after* the write with REQ_FUA.

REQ_FLUSH is indeed a flush before the write.  fdatasync is fine there too.

If you do not have REQ_FUA, as is the case with this patch, the block
layer converts it to a REQ_FLUSH *after* the write.

See block/blk-flush.c:

 * REQ_{FLUSH|FUA} requests are decomposed to sequences consisted of three
 * optional steps - PREFLUSH, DATA and POSTFLUSH - according to the request
 * properties and hardware capability.
 *
 * If the device doesn't have writeback cache, FLUSH and FUA don't make any
 * difference.  The requests are either completed immediately if there's no
 * data or executed as normal requests otherwise.
 *
 * If the device has writeback cache and supports FUA, REQ_FLUSH is
 * translated to PREFLUSH but REQ_FUA is passed down directly with DATA.
 *
 * If the device has writeback cache and doesn't support FUA, REQ_FLUSH is
 * translated to PREFLUSH and REQ_FUA to POSTFLUSH.

Paolo

  reply	other threads:[~2013-02-13 16:02 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-12 16:06 [PATCH 0/3] NBD fixes for caching and block device flags Paolo Bonzini
2013-02-12 16:06 ` [PATCH 1/3] nbd: support FLUSH requests Paolo Bonzini
2013-02-12 17:37   ` Alex Bligh
2013-02-12 18:06     ` Paolo Bonzini
2013-02-12 21:32       ` Andrew Morton
2013-02-13  0:03         ` Alex Bligh
2013-02-13 13:00           ` Paolo Bonzini
2013-02-13 15:55             ` Alex Bligh
2013-02-13 16:02               ` Paolo Bonzini [this message]
2013-02-13 17:35                 ` Alex Bligh
2013-02-13  0:00       ` Alex Bligh
2013-02-12 22:07   ` Paul Clements
2013-02-12 16:06 ` [PATCH 2/3] nbd: fsync and kill block device on shutdown Paolo Bonzini
2013-02-12 21:41   ` Andrew Morton
2013-02-13 13:05     ` Paolo Bonzini
2013-02-12 22:15   ` Paul Clements
2013-02-12 16:06 ` [PATCH 3/3] nbd: show read-only state in sysfs Paolo Bonzini
2013-02-12 22:16   ` Paul Clements
2013-02-12 21:43 ` [PATCH 0/3] NBD fixes for caching and block device flags Andrew Morton
2013-02-13 17:14   ` [Nbd] " Wouter Verhelst

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=511BB902.3080302@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=Paul.Clements@steeleye.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex@alex.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nbd-general@lists.sf.net \
    /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.