On 08/05/2015 12:08, Kevin Wolf wrote: > Actually, considering all the information in this thread, I'm inclined > that we should change both sides. qemu-nbd because ENOSPC might be what > clients expect by analogy with Linux block devices, even if the > behaviour for accesses beyond the device size isn't specified in the NBD > protocol and the server might just do anything. As long as the behaviour > is undefined, it's nice to do what most people may expect. > > And as the real fix change the nbd client, because even if new qemu-nbd > versions will be nice, we shouldn't rely on undefined behaviour. We know > that old qemu-nbd servers won't produce ENOSPC and I'm not sure what > other NBD servers do.
Sounds like a plan. > Thanks, that will be helpful in the future. > > Is this the right place to look up the spec? > http://sourceforge.net/p/nbd/code/ci/master/tree/doc/proto.txt Yes. > If so, the commands seem to be hopelessly underspecified, especially > with respect to error conditions. And where it says something about > errors, it doesn't make sense: The server is forbidden to reply to a > NBD_CMD_FLUSH if it failed... (qemu-nbd ignores this, obviously) So does nbd-server. O:-) Looks like you're reading the spec too literally (which is never a bad thing). >> Ok, so it shouldn't reach blk_check_request at all. But then, we should >> aim at making blk_check_request's checks assertions. > > Sounds fair as a goal, but I don't think all devices have such checks > yet. We've fixed the most common devices (IDE, scsi-disk and virtio-blk) > just a while ago. Indeed ("aim at"). Paolo
