[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-block] [PATCH v2 0/3] block: Warn about usage of

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v2 0/3] block: Warn about usage of growing formats over non-growable protocols
Date: Fri, 08 May 2015 12:16:59 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

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


> 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").


reply via email to

[Prev in Thread] Current Thread [Next in Thread]