[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160915120159.2o5lb7rvkjndzayh@grep.be>
Date: Thu, 15 Sep 2016 14:01:59 +0200
From: Wouter Verhelst <w@...r.be>
To: Christoph Hellwig <hch@...radead.org>
Cc: Alex Bligh <alex@...x.org.uk>,
"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>,
Markus Pargmann <mpa@...gutronix.de>, kernel-team@...com
Subject: Re: [Nbd] [RESEND][PATCH 0/5] nbd improvements
On Thu, Sep 15, 2016 at 04:52:17AM -0700, Christoph Hellwig wrote:
> On Thu, Sep 15, 2016 at 12:46:07PM +0100, Alex Bligh wrote:
> > Essentially NBD does supports FLUSH/FUA like this:
> >
> > https://www.kernel.org/doc/Documentation/block/writeback_cache_control.txt
> >
> > IE supports the same FLUSH/FUA primitives as other block drivers (AIUI).
> >
> > Link to protocol (per last email) here:
> >
> > https://github.com/yoe/nbd/blob/master/doc/proto.md#ordering-of-messages-and-writes
>
> Flush as defined by the Linux block layer (and supported that way in
> SCSI, ATA, NVMe) only requires to flush all already completed writes
> to non-volatile media.
That is precisely what FLUSH in nbd does, too.
> It does not impose any ordering unlike the nbd spec.
If you read the spec differently, then that's a bug in the spec. Can you
clarify which part of it caused that confusion? We should fix it, then.
> FUA as defined by the Linux block layer (and supported that way in SCSI,
> ATA, NVMe) only requires the write operation the FUA bit is set on to be
> on non-volatile media before completing the write operation. It does
> not impose any ordering, which seems to match the nbd spec. Unlike the
> NBD spec Linux does not allow FUA to be set on anything by WRITE
> commands. Some other storage protocols allow a FUA bit on READ
> commands or other commands that write data to the device, though.
Yes. There was some discussion on that part, and we decided that setting
the flag doesn't hurt, but the spec also clarifies that using it on READ
does nothing, semantically.
The problem is that there are clients in the wild which do set it on
READ, so it's just a matter of "be liberal in what you accept".
--
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
people in the world who think they really understand all of its rules,
and pretty much all of them are just lying to themselves too.
-- #debian-devel, OFTC, 2016-02-12
Powered by blists - more mailing lists