qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 3/5] qemu-img: Add checksum command


From: Hanna Reitz
Subject: Re: [PATCH v2 3/5] qemu-img: Add checksum command
Date: Mon, 12 Dec 2022 11:42:59 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0

On 28.11.22 15:15, Nir Soffer wrote:
The checksum command compute a checksum for disk image content using the
blkhash library[1]. The blkhash library is not packaged yet, but it is
available via copr[2].

Example run:

     $ ./qemu-img checksum -p fedora-35.qcow2
     6e5c00c995056319d52395f8d91c7f84725ae3da69ffcba4de4c7d22cff713a5  
fedora-35.qcow2

The block checksum is constructed by splitting the image to fixed sized
blocks and computing a digest of every block. The image checksum is the
digest of the all block digests.

The checksum uses internally the "sha256" algorithm but it cannot be
compared with checksums created by other tools such as `sha256sum`.

The blkhash library supports sparse images, zero detection, and
optimizes zero block hashing (they are practically free). The library
uses multiple threads to speed up the computation.

Comparing to `sha256sum`, `qemu-img checksum` is 3.5-4800[3] times
faster, depending on the amount of data in the image:

     $ ./qemu-img info /scratch/50p.raw
     file format: raw
     virtual size: 6 GiB (6442450944 bytes)
     disk size: 2.91 GiB

     $ hyperfine -w2 -r5 -p "sleep 1" "./qemu-img checksum /scratch/50p.raw" \
                                      "sha256sum /scratch/50p.raw"
     Benchmark 1: ./qemu-img checksum /scratch/50p.raw
       Time (mean ± σ):      1.849 s ±  0.037 s    [User: 7.764 s, System: 
0.962 s]
       Range (min … max):    1.813 s …  1.908 s    5 runs

     Benchmark 2: sha256sum /scratch/50p.raw
       Time (mean ± σ):     14.585 s ±  0.072 s    [User: 13.537 s, System: 
1.003 s]
       Range (min … max):   14.501 s … 14.697 s    5 runs

     Summary
       './qemu-img checksum /scratch/50p.raw' ran
         7.89 ± 0.16 times faster than 'sha256sum /scratch/50p.raw'

The new command is available only when `blkhash` is available during
build. To test the new command please install the `blkhash-devel`
package:

     $ dnf copr enable nsoffer/blkhash
     $ sudo dnf install blkhash-devel

[1] https://gitlab.com/nirs/blkhash
[2] https://copr.fedorainfracloud.org/coprs/nsoffer/blkhash/
[3] Computing checksum for 8T empty image: qemu-img checksum: 3.7s,
     sha256sum (estimate): 17,749s

Signed-off-by: Nir Soffer <nsoffer@redhat.com>
---
  docs/tools/qemu-img.rst |  24 ++++++
  meson.build             |  10 ++-
  meson_options.txt       |   2 +
  qemu-img-cmds.hx        |   8 ++
  qemu-img.c              | 183 ++++++++++++++++++++++++++++++++++++++++
  5 files changed, 226 insertions(+), 1 deletion(-)

[...]

diff --git a/qemu-img.c b/qemu-img.c
index c03d6b4b31..4b4ca7add3 100644
--- a/qemu-img.c
+++ b/qemu-img.c

[...]

@@ -1613,20 +1617,199 @@ out:
      qemu_vfree(buf1);
      qemu_vfree(buf2);
      blk_unref(blk2);
  out2:
      blk_unref(blk1);
  out3:
      qemu_progress_end();
      return ret;
  }
+#ifdef CONFIG_BLKHASH
+/*
+ * Compute image checksum.
+ */
+static int img_checksum(int argc, char **argv)
+{
+    const char *digest_name = "sha256";
+    const size_t block_size = 64 * KiB;
+
+    _Static_assert(QEMU_IS_ALIGNED(IO_BUF_SIZE, block_size),
+                   "IO_BUF_SIZE should be alligned to block_size");

(s/alligned/aligned/)

A suggestion: We have a `QEMU_BUILD_BUG_MSG()` macro in include/qemu/compiler.h.  Nowadays it just unconditionally resolves to _Static_assert, I think before C11 was adopted it used a custom implementation.  Still, it is what seems to be used throughout the actual qemu code (disregarding roms/ and pc-bios/), so I think it would be more fitting to use.

But that’s just a suggestion.  It always resolves to _Static_assert anyway, so using _Static_assert seems by no means wrong.

So with the spelling fixed:

Reviewed-by: Hanna Reitz <hreitz@redhat.com>




reply via email to

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