Am 18.09.2014 um 16:13 schrieb Paolo Bonzini <pbonz...@redhat.com>:
> Il 05/09/2014 18:51, Peter Lieven ha scritto:
>> Signed-off-by: Peter Lieven <p...@kamp.de>
>> ---
>> block.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/block.c b/block.c
>> index fa4c34b..db3f842 100644
>> --- a/block.c
>> +++ b/block.c
>> @@ -4554,6 +4554,11 @@ static int multiwrite_merge(BlockDriverState *bs,
>> BlockRequest *reqs,
>> merge = 0;
>> }
>>
>> + if (bs->bl.max_transfer_length && reqs[outidx].nb_sectors +
>> + reqs[i].nb_sectors > bs->bl.max_transfer_length) {
>> + merge = 0;
>> + }
>> +
>> if (merge) {
>> size_t size;
>> QEMUIOVector *qiov = g_malloc0(sizeof(*qiov));
>>
>
> So I think if we treat it just as a hint for multiwrite, we can avoid
> writing code to split oversized requests. They always worked so far, we
> can certainly wait until we have a real bug fix.
I would not treat this as a hint. I would use it in cases where we definitely
know an absolute hard limit for I/O request size. Otherwise the value for
bs->bl.max_transfer_length should be 0.
If there comes in an oversized request we fail it as early as possible and
regarding
the multi write code we avoid that it accidentally generates an oversized
request.
Peter
