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 14:00:21 +0100 [thread overview]
Message-ID: <511B8E65.5020507@redhat.com> (raw)
In-Reply-To: <FF1216D8-C4B3-405E-A4F6-82196A796A94@alex.org.uk>
Il 13/02/2013 01:03, Alex Bligh ha scritto:
>> > Obviously the changelog was inadequate. Please send along a new one
>> > which fully describes the reasons for this change.
> To be clear I have no complaints about the rest of the patch being
> merged. Supporting FLUSH but not FUA is far better than supporting
> neither. I just didn't understand dropping FUA given the semantics
> of nbd is in essence 'linux bios over tcp'.
Not really bios, since it expects FLUSH requests to include no I/O, but
yes the semantics of NBD (and virtio-blk) are quite close to those of
the Linux block layer.
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?).
Andrew, here is a better commit message:
------------ 8< ---------------
From: Alex Bligh <alex@alex.org.uk>
Subject: nbd: support FLUSH requests
Currently, the NBD device does not accept flush requests from the Linux
block layer. If the NBD server opened the target with neither O_SYNC
nor O_DSYNC, however, the device will be effectively backed by a
writeback cache. Without issuing flushes properly, operation of the NBD
device will not be safe against power losses.
The NBD protocol has support for both a cache flush command and a FUA
command flag; the server will also pass a flag to note its support for
these features. This patch adds support for the cache flush command and
flag. In the kernel, we receive the flags via the NBD_SET_FLAGS ioctl,
and map NBD_FLAG_SEND_FLUSH to the argument of blk_queue_flush. When
the flag is active the block layer will send REQ_FLUSH requests, which
we translate to NBD_CMD_FLUSH commands.
FUA support is not included in this patch because all free software
servers implement it with a full fdatasync; thus it has no advantage
over supporting flush only. Because I [Paolo] cannot really benchmark
it in a realistic scenario, I cannot tell if it is a good idea or not.
It is also not clear if it is valid for an NBD server to support FUA but
not flush. The Linux block layer gives a warning for this combination,
the NBD protocol documentation says nothing about it.
The patch also fixes a small problem in the handling of flags:
nbd->flags must be cleared at the end of NBD_DO_IT, but the driver was
not doing that. The bug manifests itself as follows. Suppose you two
different client/server pairs to start the NBD device. Suppose also
that the first client supports NBD_SET_FLAGS, and the first server sends
NBD_FLAG_SEND_FLUSH; the second pair instead does neither of these two
things. Before this patch, the second invocation of NBD_DO_IT will use
a stale value of nbd->flags, and the second server will issue an error
every time it receives an NBD_CMD_FLUSH command.
This bug is pre-existing, but it becomes much more important after this
patch; flush failures make the device pretty much unusable, unlike
discard failures.
Signed-off-by: Alex Bligh <alex@alex.org.uk>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Cc: Paul Clements <Paul.Clements@steeleye.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
Paolo
next prev parent reply other threads:[~2013-02-13 13:01 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 [this message]
2013-02-13 15:55 ` Alex Bligh
2013-02-13 16:02 ` Paolo Bonzini
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=511B8E65.5020507@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.