On Wed, Dec 10, 2014 at 8:55 PM, Paolo Bonzini <pbonz...@redhat.com> 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
