Am 23.09.2014 um 10:55 hat Peter Lieven geschrieben:
> >> - should we only merge requests within the same cluster?
> >Does it hurt to merge everything we can? The block driver needs to be
> >able to take things apart anyway, the large request could come from
> >somewhere else (guest, block job, bu
On 23.09.2014 10:47, Kevin Wolf wrote:
Am 08.09.2014 um 16:54 hat Peter Lieven geschrieben:
On 08.09.2014 16:42, Paolo Bonzini wrote:
Il 08/09/2014 16:35, Peter Lieven ha scritto:
Whats your opinion changed the max_xfer_len to 0x regardsless
of use_16_for_rw in iSCSI?
If you implemented r
Am 08.09.2014 um 16:54 hat Peter Lieven geschrieben:
> On 08.09.2014 16:42, Paolo Bonzini wrote:
> >Il 08/09/2014 16:35, Peter Lieven ha scritto:
> >>Whats your opinion changed the max_xfer_len to 0x regardsless
> >>of use_16_for_rw in iSCSI?
> >If you implemented request splitting in the block
Am 18.09.2014 um 16:17 schrieb Paolo Bonzini :
> Il 18/09/2014 16:16, Peter Lieven ha scritto:
>>>
As you can see from the multiwrite_merge trace the merging has never
been stopped because of
the max_transfer_length. The question is, why are the I/O requests
not coming in as
Il 18/09/2014 16:16, Peter Lieven ha scritto:
>>
>>> As you can see from the multiwrite_merge trace the merging has never
>>> been stopped because of
>>> the max_transfer_length. The question is, why are the I/O requests
>>> not coming in as specified?
>> I think that's because of the filesystem.
On 18.09.2014 16:12, Paolo Bonzini wrote:
Il 12/09/2014 13:43, Peter Lieven ha scritto:
As you can see from the multiwrite_merge trace the merging has never been
stopped because of
the max_transfer_length. The question is, why are the I/O requests not coming
in as specified?
I think that's be
Il 12/09/2014 13:43, Peter Lieven ha scritto:
>
> As you can see from the multiwrite_merge trace the merging has never been
> stopped because of
> the max_transfer_length. The question is, why are the I/O requests not coming
> in as specified?
I think that's because of the filesystem. Try writ
Am 08.09.2014 um 18:29 schrieb Paolo Bonzini:
> Il 08/09/2014 18:18, Peter Lieven ha scritto:
When copying data, gparted will try using very large I/O sizes. Of
course if something breaks it will just use a smaller size, but it would
make performance worse.
I tried now (wi
Il 08/09/2014 18:18, Peter Lieven ha scritto:
>> > When copying data, gparted will try using very large I/O sizes. Of
>> > course if something breaks it will just use a smaller size, but it would
>> > make performance worse.
>> >
>> > I tried now (with local storage, not virtual---but with such l
> Am 08.09.2014 um 17:27 schrieb Paolo Bonzini :
>
> Il 08/09/2014 17:18, Peter Lieven ha scritto:
>>>
>>> That's why we have splitting code for discard, and why we would have to
>>> add it for read/write too.
>>
>> Why should a guest generate such big requests.
>
> When copying data, gparted
Il 08/09/2014 17:18, Peter Lieven ha scritto:
>>
>> That's why we have splitting code for discard, and why we would have to
>> add it for read/write too.
>
> Why should a guest generate such big requests.
When copying data, gparted will try using very large I/O sizes. Of
course if something brea
On 08.09.2014 17:15, Paolo Bonzini wrote:
Il 08/09/2014 17:13, ronnie sahlberg ha scritto:
What I would like to see would also be to report these limitations to
the guest itself to prevent it from generating too large I/Os.
That's difficult because you don't want a backend change (e.g. from
loc
On 08.09.2014 17:13, ronnie sahlberg wrote:
On Mon, Sep 8, 2014 at 7:42 AM, Paolo Bonzini wrote:
Il 08/09/2014 16:35, Peter Lieven ha scritto:
messages. :)
So you would not throw an error msg here?
No, though a trace could be useful.
Is there a howto somewhere how to implement that?
Try co
Il 08/09/2014 17:13, ronnie sahlberg ha scritto:
>
> What I would like to see would also be to report these limitations to
> the guest itself to prevent it from generating too large I/Os.
That's difficult because you don't want a backend change (e.g. from
local storage to iSCSI) to change the vit
On Mon, Sep 8, 2014 at 7:42 AM, Paolo Bonzini wrote:
> Il 08/09/2014 16:35, Peter Lieven ha scritto:
>
> messages. :)
So you would not throw an error msg here?
>>> No, though a trace could be useful.
>>
>> Is there a howto somewhere how to implement that?
>
> Try commit 4ac4458076e1aa
On 08.09.2014 16:42, Paolo Bonzini wrote:
Il 08/09/2014 16:35, Peter Lieven ha scritto:
messages. :)
So you would not throw an error msg here?
No, though a trace could be useful.
Is there a howto somewhere how to implement that?
Try commit 4ac4458076e1aaf3b01a6361154117df20e22215.
Thanks f
Il 08/09/2014 16:35, Peter Lieven ha scritto:
messages. :)
>>> So you would not throw an error msg here?
>> No, though a trace could be useful.
>
> Is there a howto somewhere how to implement that?
Try commit 4ac4458076e1aaf3b01a6361154117df20e22215.
> Whats your opinion changed the ma
On 08.09.2014 15:58, Paolo Bonzini wrote:
Il 08/09/2014 15:56, Peter Lieven ha scritto:
Look like you are changing the coroutine version.
Some hardware like virtio-blk uses the AIO version of read and writes.
What would happen if all the block drivers down the chain are AIO
enabled ?
The AIO v
Il 08/09/2014 15:56, Peter Lieven ha scritto:
>
>>> Look like you are changing the coroutine version.
>>>
>>> Some hardware like virtio-blk uses the AIO version of read and writes.
>>> What would happen if all the block drivers down the chain are AIO
>>> enabled ?
>> The AIO version still goes
On 08.09.2014 15:49, Paolo Bonzini wrote:
Il 08/09/2014 15:44, Benoît Canet ha scritto:
+if (bs->bl.max_transfer_length && nb_sectors > bs->bl.max_transfer_length)
{
+error_report("read of %d sectors at sector %ld exceeds device max"
+ " transfer length of %d sec
Il 08/09/2014 15:44, Benoît Canet ha scritto:
>> > +if (bs->bl.max_transfer_length && nb_sectors >
>> > bs->bl.max_transfer_length) {
>> > +error_report("read of %d sectors at sector %ld exceeds device max"
>> > + " transfer length of %d sectors.", nb_sectors,
>> >
The Friday 05 Sep 2014 à 18:51:26 (+0200), Peter Lieven wrote :
> Signed-off-by: Peter Lieven
> ---
> block.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/block.c b/block.c
> index 2c4a5de..fa4c34b 100644
> --- a/block.c
> +++ b/block.c
> @@ -3215,6 +3215,13 @@ stat
Signed-off-by: Peter Lieven
---
block.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/block.c b/block.c
index 2c4a5de..fa4c34b 100644
--- a/block.c
+++ b/block.c
@@ -3215,6 +3215,13 @@ static int coroutine_fn
bdrv_co_do_readv(BlockDriverState *bs,
return -EINVAL;
23 matches
Mail list logo
