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 layer, it
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
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, builtin
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 writing
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
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. Try writing
Am 18.09.2014 um 16:17 schrieb Paolo Bonzini pbonz...@redhat.com:
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
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 (with local storage,
The Friday 05 Sep 2014 à 18:51:26 (+0200), Peter Lieven wrote :
Signed-off-by: Peter Lieven p...@kamp.de
---
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 @@
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 through
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
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 max_xfer_len to
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
On Mon, Sep 8, 2014 at 7:42 AM, Paolo Bonzini pbonz...@redhat.com 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
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 vital
On 08.09.2014 17:13, ronnie sahlberg wrote:
On Mon, Sep 8, 2014 at 7:42 AM, Paolo Bonzini pbonz...@redhat.com 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
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
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 breaks it
Am 08.09.2014 um 17:27 schrieb Paolo Bonzini pbonz...@redhat.com:
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,
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 large block
Signed-off-by: Peter Lieven p...@kamp.de
---
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,
21 matches
Mail list logo
