On Wed, Dec 10, 2014 at 5:56 PM, Paolo Bonzini <pbonz...@redhat.com> wrote: > > > On 10/12/2014 02:41, Ming Lei wrote: >> On Wed, Dec 10, 2014 at 1:45 AM, Paolo Bonzini <pbonz...@redhat.com> wrote: >>> >>> >>> On 08/12/2014 08:19, Ming Lei wrote: >>>>>> >>>>>> Alternatively, I'd accept a SCSI patch setting max_ws_blocks and friends >>>>>> to 2GB - 1 block. >>>> It should be better to not introduce the limit and split the writes >>>> into size of 2GB - 1 block since there is only the limit for write zero. >>> >>> Why? That's exactly what the max_ws_blocks is for, and there's code in >>> the guest already to do the split. We're talking about 2GB, not 1MB. >> >> The split in write same does not cover write zero, and that is the problem. >> Otherwise write same just works fine. That said write same of QEMU SCSI >> can work well without max write same sectors limit. >> >> If we introduce the limit of max write same sectors, this limit will be put >> on both write zero and write non-zero path. > > Yeah, but the 2GB limit happens also for the regular I/O path. The > quirk is that it doesn't happen for non-zero WRITE SAME, not the other > way round. > >> Also "MAXIMUM WRITE SAME LENGTH" is just introduced on sbc3r35 >> in Jan, 2013, and some old host drivers may not support it, and not using >> the limit should have better compatibility. > > 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? It is _not_ never happen at all, and easy to be triggered when using mkfs. Thanks,
