Re: [Qemu-devel] [Qemu-block] [PATCH v2 0/3] block: Warn about usage of growing formats over non-growable protocols

[Max Reitz <mreitz@redhat.com>]

On 06.05.2015 18:47, Paolo Bonzini wrote:
>
> On 06/05/2015 18:37, Max Reitz wrote:
>> Because qcow2 tries to write beyond the end of the file; the NBD client
>> implementation passes that on to the server, and the server simply
>> reports an error (which the NBD client turns into EIO).
> Where?
>
>      qemu_coroutine_yield();
>      *reply = s->reply;
>      if (reply->handle != request->handle) {
>          reply->error = EIO;
>      } else {
>          if (qiov && reply->error == 0) {
>              ret = qemu_co_recvv(s->sock, qiov->iov, qiov->niov,
>                                  offset, request->len);
>              if (ret != request->len) {
>                  reply->error = EIO;
>              }
>          }
>
>          /* Tell the read handler to read another header.  */
>          s->reply.handle = 0;
>      }
>
> It should get into the "else" and then see reply->error != 0.  So the
> guest should see ENOSPC.

The guest sees whatever has been written into reply->error, and that 
field hasn't been written by this function in that case. It has been 
written by nbd_receive_reply() in nbd.c, and that value comes directly 
from the server. In case of qemu-nbd being the server, a write beyond 
the EOF should be caught by blk_check_byte_request() in 
block/block-backend.c, which returns -EIO. So that's where the EIO comes 
from.

I don't know whether this EIO is subsequently converted to ENOSPC 
because of werror=enospc, but considering that 
https://bugzilla.redhat.com/show_bug.cgi?id=1090713 did not override 
werror, it doesn't look like it.

>>> Can you check if virtio-scsi
>>> gives ENOSPC?
>> In which configuration? Using virtio-scsi on top of qcow2 on top of some
>> SCSI passthrough block driver?  Sounds like we ought to make NBD return
>> ENOSPC no matter the fate of this series.
> virtio-scsi on top of qcow2 on top of NBD.  No passthrough: "-device
> scsi-disk" should work.  It seems to me that NBD _should_ be getting
> ENOSPC, unless it's nbd-server that throws away the error.

Well, nbd-server will return whatever it feels like, I don't know about 
that. qemu-nbd on the other hand I do know about, and as written above, 
it will return EIO because of the check performed from blk_write(). So 
that error is sent to the client, where the nbd BDS will return it, too, 
and then qcow2 will propagate it up to virtio-scsi. It looks to me like 
scsi_handle_rw_error() will then call scsi_check_condition(r, 
SENSE_CODE(IO_ERROR)).

(Note that I think werror is only used for block jobs, but not for 
normal guest operations, so EIO coming from a BDS is not converted to 
ENOSPC for guest requests)

I can test these assumptions, if you'd like me to, but that will have to 
wait until Friday. :-)

Max

>> The problem with only warning for a certain non-default configuration is
>> that people who don't know what they are doing are more likely to use
>> the default configuration, so I'd like the warning to appear then.
> That's entirely true.  Perhaps the werror default should be changed from
> enospc to report after all!
>
> Paolo