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 for the pointer.
Whats your opinion changed the max_xfer_len to 0xffff regardsless
of use_16_for_rw in iSCSI?
If you implemented request splitting in the block layer, it would be
okay to force max_xfer_len to 0xffff.
Unfortunately, I currently have no time for that. It will include some
shuffling with
qiovs that has to be properly tested.
Regarding iSCSI: In fact currently the limit is 0xffff for all iSCSI Targets <
2TB.
So I thought that its not obvious at all why a > 2TB target can handle bigger
requests.
To the root cause of this patch multiwrite_merge I still have some thoughts:
- why are we merging requests for raw (especially host devices and/or iSCSI?)
The original patch from Kevin was to mitigate a QCOW2 performance regression.
For iSCSI the qiov concats are destroying all the zerocopy efforts we made.
- should we only merge requests within the same cluster?
- why is there no multiread_merge?
Peter
