[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 6/8] block: request overlap detection
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [PATCH v2 6/8] block: request overlap detection |
Date: |
Tue, 22 Nov 2011 16:06:05 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0 |
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?
Kevin
- [Qemu-devel] [PATCH v2 0/8] block: generic copy-on-read, Stefan Hajnoczi, 2011/11/17
- [Qemu-devel] [PATCH v2 8/8] block: add -drive copy-on-read=on|off, Stefan Hajnoczi, 2011/11/17
- [Qemu-devel] [PATCH v2 3/8] block: add request tracking, Stefan Hajnoczi, 2011/11/17
- [Qemu-devel] [PATCH v2 2/8] coroutine: add qemu_co_queue_restart_all(), Stefan Hajnoczi, 2011/11/17
- [Qemu-devel] [PATCH v2 4/8] block: add bdrv_set_copy_on_read(), Stefan Hajnoczi, 2011/11/17
- [Qemu-devel] [PATCH v2 5/8] block: wait for overlapping requests, Stefan Hajnoczi, 2011/11/17
- [Qemu-devel] [PATCH v2 7/8] block: core copy-on-read logic, Stefan Hajnoczi, 2011/11/17