> 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.
My current patchset have a big dedup_lock co mutex.
I'll replace it with the overlapping request solution.
> Where do you see an issue - do you thin
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
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 prob
$ ./check -qcow2 026
[...]
Event: l1_grow.activate_table; errno: 5; imm: off; once: on
wrote 65536/65536 bytes at offset 0
64 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
ERROR: cluster 14482163507622771: copied flag must never be set for
compressed clusters
Warning: cluster offset=0xdcdcdc
On Mon, Nov 26, 2012 at 02:04:59PM +0100, Benoît Canet wrote:
> This patchset is the first working version of the QCOW2 deduplication.
>
> Images must be created with "-o dedup=on" in order to activate the
> deduplication in the image.
>
>
> Since v2: make it work barely
> replace kern
This patchset is the first working version of the QCOW2 deduplication.
Images must be created with "-o dedup=on" in order to activate the
deduplication in the image.
Since v2: make it work barely
replace kernel red black trees by gtree.
Benoît Canet (24):
qcow2: Add deduplication to