[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?


reply via email to

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