Re: [Nbd] NBD_CMD_FLAG_FUA
- To: Alex Bligh <alex@...872...>
- Cc: nbd-general@lists.sourceforge.net
- Subject: Re: [Nbd] NBD_CMD_FLAG_FUA
- From: Wouter Verhelst <w@...112...>
- Date: Thu, 31 Mar 2016 19:14:45 +0200
- Message-id: <20160331171445.GC2448@...3...>
- In-reply-to: <F6D60393-3D44-491F-83CF-01E020CCB9C5@...872...>
- References: <F6D60393-3D44-491F-83CF-01E020CCB9C5@...872...>
On Thu, Mar 31, 2016 at 11:36:14AM +0100, Alex Bligh wrote:
> >From proto.md:
>
> > If the NBD_FLAG_SEND_FUA flag ("Force Unit Access") was set in the export
> > flags field, the client MAY set the flag NBD_CMD_FLAG_FUA in the command
> > flags field. If this flag was set, the server MUST NOT send the reply until
> > it has ensured that the newly-written data has reached permanent storage.
>
> NBD_CMD_FLAG_FUA itself is not defined in proto.md
It wasn't originally, but that has been fixed two days ago :-)
> nbd.h has:
>
> #define NBD_CMD_FLAG_FUA (1<<16)
>
> This is a bit odd as the command flags are only 16 bits long!
>
> I think I may be the only person who has ever implemented a server side FUA,
> but I think this is a legacy of when commands were originally 32 bits long
> and we broke 16 bits off for flags.
Correct. I probably should've cleaned that up years ago, but it's only
been since fairly recently that I started considering the "command" and
"flags" fields to be separate fields, rather than having the flags field
be a "subfield" of sorts to the command field.
[...]
> Now flags are a separate field (and command is 16 bits), I think we should have in nbd.h
>
> #define NBD_CMD_FLAG_FUA (1<<0)
>
> and this should also be in proto.md.
>
> Wouter: would you take a patch?
Sure (provided it doesn't break things :-).
--
< 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
Reply to: