On Mon, Sep 8, 2014 at 7:42 AM, Paolo Bonzini <address@hidden> 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.
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.
I think it should be OK if that is a different series. This only
affects the iSCSI transport since it is the only transport so far to
record or report a max transfer length.
If a guest generates these big requests(i.e. not multiwrite) we
already fail them due to the READ10 limitations. We would just fail
the request at a different layer in the stack with these patches.
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.
I am willing to do that part once the initial max_xfer_len ones are finished.