On Wed, Dec 12, 2012 at 04:57:38PM +0100, Benoît Canet wrote:
Can you foresee the need to use a different hash algorithm in the future
and should we add a hash_algo enum field to the dedup QCOW2 header
extension?
Yes I foresee the future use of faster hash function like SHA3 or Skein.
Can you foresee the need to use a different hash algorithm in the future
and should we add a hash_algo enum field to the dedup QCOW2 header
extension?
Yes I foresee the future use of faster hash function like SHA3 or Skein.
I also think an alternate deduplication mechanism where lookups are
32+8 is not a power of two; what happens to the tail bytes at the end of
a cluster of entries? If you define them to be 0 now, you can use them
for possible extensions later.
They are currently unused. That's a nice idea.
Benoît
On Mon, Nov 26, 2012 at 02:05:00PM +0100, Benoît Canet wrote:
Signed-off-by: Benoit Canet ben...@irqsave.net
---
docs/specs/qcow2.txt | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/docs/specs/qcow2.txt b/docs/specs/qcow2.txt
index
On Mon, Nov 26, 2012 at 02:05:00PM +0100, Benoît Canet wrote:
+== Deduplication table ==
+
+The deduplication table contains 64 bits offsets to the level 2 deduplication
+table clusters.
+Each entry of these clusters contains a 32 bytes SHA256 hash followed by the
+64 bits logical offset of
On 11/26/2012 06:05 AM, Benoît Canet wrote:
Signed-off-by: Benoit Canet ben...@irqsave.net
---
docs/specs/qcow2.txt | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
In addition to Stefan's comments,
@@ -159,6 +163,33 @@ the header extension data.
Signed-off-by: Benoit Canet ben...@irqsave.net
---
docs/specs/qcow2.txt | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/docs/specs/qcow2.txt b/docs/specs/qcow2.txt
index 36a559d..16eafd7 100644
--- a/docs/specs/qcow2.txt
+++
