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
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
_______________________________________________
Nbd-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nbd-general
