[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC V3 00/24] QCOW2 deduplication
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [RFC V3 00/24] QCOW2 deduplication |
Date: |
Tue, 18 Dec 2012 14:42:39 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Wed, Dec 12, 2012 at 05:14:28PM +0100, Benoît Canet wrote:
>
> Hi Stefan,
>
> I have a few questions
>
> 1) overlapping sequential sub-cluster writes
>
> The current code pass most of the tests and behave well with a 4KB cluster
> sized
> ext3 volume on the deduplicated image.
>
> But less than cluster size sequentials writes are troublesome.
> They fail with xfstest.
> The problem is that the lock is released twice so that coherency is not
> garanteed when two sub cluster size write are done on the same area.
> (a deduplication attempt is done while the first write is yet not on disk)
>
> My understanding is that a wait_for_overlapping_cluster_write function called
> before the writev loop in order to serialize such writes would solve the
> problem.
> What do you this of this idea ?
Yes, it's the same problem that copy-on-read has. We can serialize I/O
requests, if necessary, in order to prevent them racing with each other.
> 2) Internal snapshot
> I don't fully understand if the current deduplication implementation is
> compatible with internal snapshots. If not could it be done on a latter
> patchset ?
Let's figure out how hard it is to support internal snapshots for dedup.
Internal snapshot creation is simple:
1. Copy the current L1 table for the internal snapshot.
2. Increment refcounts for L2 and data clusters.
3. Finalize the internal snapshot.
Where do you see an issue - do you think the refcount manipulations
you're doing for dedup might conflict with internal snapshots?
Stefan