Re: [Qemu-devel] [PATCH] block: fix big write

[Ming Lei]

On Wed, Dec 10, 2014 at 8:55 PM, Paolo Bonzini <address@hidden> wrote:
>
>
> On 10/12/2014 13:23, Ming Lei wrote:
>>> >
>>> > Again, we're talking of 2GB and this is something that should never
>>> > happen in practice.
>> Again, the 2GB limit can be avoided if I/O is splitted, isn't it?
>
> Sure.  The guest kernel is doing the split.

QEMU SCSI can do it transparently.

>
>> It is _not_ never happen at all, and easy to be triggered when using
>> mkfs.
>
> mkfs is not something to optimize for, it's just something that should
> work.  (Also, some hardware may time out if you do write same with too
> high a block count).

I don't think it is related with the hardware time out issue since your
patch still splits the block count into 2G - 1, and both are same wrt.
block count.

>
> Both Linux and Windows will always use UNMAP on QEMU, except for the
> small time period where Linux used WRITE SAME and this bug was
> discovered.  And all versions of Linux that used WRITE SAME honored the
> max_ws_blocks field.

Not sure how you get the conclusion.

Firstly some old host scsi drivers can't respect max_ws_blocks
block limits since it is just introduced in last year.

Secondly SBC-3 draft doesn't describe the priority explicitly among
UNMAP, WRITE SAME 10, and WRITE SAME 16, so it is driver's
freedom to take anyone in theory.

Finally blkdev_issue_zeroout() can send WRITE SAME(10/16) directly
and it can be from user space, fs, and block drivers.

Thanks,
Ming Lei