qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 6/8] block: request overlap detection


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH v2 6/8] block: request overlap detection
Date: Tue, 22 Nov 2011 15:10:20 +0000

On Tue, Nov 22, 2011 at 3:06 PM, Kevin Wolf <address@hidden> wrote:
> Am 17.11.2011 14:40, schrieb Stefan Hajnoczi:
>> Detect overlapping requests and remember to align to cluster boundaries
>> if the image format uses them.  This assumes that allocating I/O is
>> performed in cluster granularity - which is true for qcow2, qed, etc.
>>
>> Signed-off-by: Stefan Hajnoczi <address@hidden>
>
>>  static void coroutine_fn wait_for_overlapping_requests(BlockDriverState *bs,
>>          int64_t sector_num, int nb_sectors)
>>  {
>>      BdrvTrackedRequest *req;
>> +    int64_t cluster_sector_num;
>> +    int cluster_nb_sectors;
>>      bool retry;
>>
>> +    /* If we touch the same cluster it counts as an overlap */
>> +    round_to_clusters(bs, sector_num, nb_sectors,
>> +                      &cluster_sector_num, &cluster_nb_sectors);
>
> Is this really required? Image formats must be able to deal with two
> concurrent write requests to the same cluster, and I don't think it
> makes a difference whether it's a guest write request or a COR one.
>
> Or does the queuing protect more than just that a COR never takes
> precedence over a guest write?

It guarantees that a write request and a copy-on-read request racing
for the same cluster will be serialized.  Either:
1. CoR, then write.
2. Allocating write, then normal read.

If we don't do this we risk:
3. CoR (part 1: read), allocating write, CoR (part 2: write)

The result is that we dropped the write request!

Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]