On 01/04/2016 18:08, Eric Blake wrote: > The NBD protocol does not clearly document what will happen > if a client sends NBD_CMD_FLAG_FUA on NBD_CMD_FLUSH. > Historically, both the qemu and upstream NBD servers silently > ignored that flag, but that feels a bit risky. Meanwhile, the > qemu NBD client unconditionally sends the flag (without even > bothering to check whether the caller cares; at least with > NBD_CMD_WRITE the client only sends FUA if requested by a > higher layer). > > There is ongoing discussion on the NBD list to fix the > protocol documentation to require that the server MUST ignore > the flag (unless the kernel folks can better explain what FUA > means for a flush), but until those doc improvements land, the > current nbd.git master was recently changed to reject the flag > with EINVAL (see nbd commit ab22e082), which now makes it > impossible for a qemu client to use FLUSH with an upstream NBD > server. > > We should not send FUA with flush unless the upstream protocol > documents what it will do, and even then, it should be something > that the caller can opt into, rather than being unconditional. > > Signed-off-by: Eric Blake <[email protected]> > --- > block/nbd-client.c | 4 ---- > 1 file changed, 4 deletions(-) > > diff --git a/block/nbd-client.c b/block/nbd-client.c > index 021a88b..878e879 100644 > --- a/block/nbd-client.c > +++ b/block/nbd-client.c > @@ -319,10 +319,6 @@ int nbd_client_co_flush(BlockDriverState *bs) > return 0; > } > > - if (client->nbdflags & NBD_FLAG_SEND_FUA) { > - request.type |= NBD_CMD_FLAG_FUA; > - } > - > request.from = 0; > request.len = 0; >
Thanks, queued for 2.6. Paolo
