On 10/12/2014 16:47, Ming Lei wrote:
> > > Finally blkdev_issue_zeroout() can send WRITE SAME(10/16) directly
> > > and it can be from user space, fs, and block drivers.
> >
> > That is WRITE SAME without UNMAP, it is not used by mkfs, and Linux has
> > always honored max_write_same_blocks for it
On Wed, Dec 10, 2014 at 11:02 PM, Paolo Bonzini wrote:
>
>
> On 10/12/2014 15:35, Ming Lei wrote:
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
On 10/12/2014 15:35, Ming Lei wrote:
>>> 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).
>
On Wed, Dec 10, 2014 at 8:55 PM, Paolo Bonzini 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 kerne
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.
> It is _not_ never happen at all, and easy
On Wed, Dec 10, 2014 at 5:56 PM, Paolo Bonzini wrote:
>
>
> On 10/12/2014 02:41, Ming Lei wrote:
>> On Wed, Dec 10, 2014 at 1:45 AM, Paolo Bonzini wrote:
>>>
>>>
>>> On 08/12/2014 08:19, Ming Lei wrote:
>>
>> Alternatively, I'd accept a SCSI patch setting max_ws_blocks and friends
>>
On 10/12/2014 02:41, Ming Lei wrote:
> On Wed, Dec 10, 2014 at 1:45 AM, Paolo Bonzini 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 lim
On Wed, Dec 10, 2014 at 1:45 AM, Paolo Bonzini 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 -
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? Tha
On Sat, Dec 6, 2014 at 12:33 AM, Paolo Bonzini wrote:
>
>
> On 05/12/2014 17:15, Ming Lei wrote:
>> From: Ming Lei
>>
>> QEMU block should have supported to read/write at most
>> 0x7f * 512 bytes, unfortunately INT_MAX is used to check
>> bytes in both bdrv_co_do_writev() and bdrv_check_byte_
On 05/12/2014 18:03, Max Reitz wrote:
> On 2014-12-05 at 17:15, Ming Lei wrote:
>> From: Ming Lei
>>
>> QEMU block should have supported to read/write at most
>> 0x7f * 512 bytes, unfortunately INT_MAX is used to check
>> bytes in both bdrv_co_do_writev() and bdrv_check_byte_request(),
>> so
On 2014-12-05 at 17:15, Ming Lei wrote:
From: Ming Lei
QEMU block should have supported to read/write at most
0x7f * 512 bytes, unfortunately INT_MAX is used to check
bytes in both bdrv_co_do_writev() and bdrv_check_byte_request(),
so cause write failure if nr_sectors is equal or more
than
On 05/12/2014 17:15, Ming Lei wrote:
> From: Ming Lei
>
> QEMU block should have supported to read/write at most
> 0x7f * 512 bytes, unfortunately INT_MAX is used to check
> bytes in both bdrv_co_do_writev() and bdrv_check_byte_request(),
> so cause write failure if nr_sectors is equal or m
From: Ming Lei
QEMU block should have supported to read/write at most
0x7f * 512 bytes, unfortunately INT_MAX is used to check
bytes in both bdrv_co_do_writev() and bdrv_check_byte_request(),
so cause write failure if nr_sectors is equal or more
than 0x40.
There are still other INT_MAX u
14 matches
Mail list logo
