| Message ID | 1459526902-32561-1-git-send-email-eblake@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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 <eblake@redhat.com> > --- > 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
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;
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 <eblake@redhat.com> --- block/nbd-client.c | 4 ---- 1 file changed, 4 deletions(-)