qemu-devel
[Top][All Lists]
Advanced

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

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


From: Ming Lei
Subject: Re: [Qemu-devel] [PATCH] block: fix big write
Date: Wed, 10 Dec 2014 20:23:51 +0800

On Wed, Dec 10, 2014 at 5:56 PM, Paolo Bonzini <address@hidden> wrote:
>
>
> On 10/12/2014 02:41, Ming Lei wrote:
>> On Wed, Dec 10, 2014 at 1:45 AM, Paolo Bonzini <address@hidden> 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,



reply via email to

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