[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <751994A2-653B-4201-8210-A31495804788@alex.org.uk>
Date: Thu, 15 Sep 2016 12:43:35 +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>, Josef Bacik <jbacik@...com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
linux-block@...r.kernel.org, Markus Pargmann <mpa@...gutronix.de>,
kernel-team@...com
Subject: Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements
Christoph,
> On 15 Sep 2016, at 12:38, Christoph Hellwig <hch@...radead.org> wrote:
>
> On Thu, Sep 15, 2016 at 12:49:35PM +0200, Wouter Verhelst wrote:
>> A while back, we spent quite some time defining the semantics of the
>> various commands in the face of the NBD_CMD_FLUSH and NBD_CMD_FLAG_FUA
>> write barriers. At the time, we decided that it would be unreasonable
>> to expect servers to make these write barriers effective across
>> different connections.
>
> Do you have a nbd protocol specification? treating a flush or fua
> as any sort of barrier is incredibly stupid. Is it really documented
> that way, and if yes, why?
Sure, it's at:
https://github.com/yoe/nbd/blob/master/doc/proto.md#ordering-of-messages-and-writes
and that link takes you to the specific section.
The treatment of FLUSH and FUA is meant to mirror exactly the
linux block layer (or rather how the linux block layer was a few
years ago). I even asked on LKML to verify a few points.
--
Alex Bligh
Powered by blists - more mailing lists