[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <2ABB8966-5C20-45A7-BB4C-6882F042905D@alex.org.uk>
Date: Thu, 15 Sep 2016 13:33:20 +0100
From: Alex Bligh <alex@...x.org.uk>
To: Christoph Hellwig <hch@...radead.org>
Cc: Alex Bligh <alex@...x.org.uk>, Wouter Verhelst <w@...r.be>,
"nbd-general@...ts.sourceforge.net"
<nbd-general@...ts.sourceforge.net>, linux-block@...r.kernel.org,
Josef Bacik <jbacik@...com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
mpa@...gutronix.de, kernel-team@...com
Subject: Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements
> On 15 Sep 2016, at 13:23, Christoph Hellwig <hch@...radead.org> wrote:
>
> On Thu, Sep 15, 2016 at 02:21:20PM +0200, Wouter Verhelst wrote:
>> Right. So do I understand you correctly that blk-mq currently doesn't
>> look at multiple queues, and just assumes that if a FLUSH is sent over
>> any one of the queues, it applies to all queues?
>
> Yes. The same is true at the protocol level for NVMe or SCSI transports
> that can make use of multiple queues.
At an implementation level that is going to be a little difficult
for some NBD servers, e.g. ones that fork() a different process per
connection. There is in general no IPC to speak of between server
instances. Such servers would thus be unsafe with more than one
connection if FLUSH is in use.
I believe such servers include the reference server where there is
process per connection (albeit possibly with several threads).
Even single process servers (including mine - gonbdserver) would
require logic to pair up multiple connections to the same
device.
I suspect ALL nbd servers would require a change. So I think we should
think carefully before introducing this protocol change.
It might be easier to make the client code change work around this
issue (somehow).
--
Alex Bligh
Powered by blists - more mailing lists