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

Re: [Libguestfs] [PATCH 3/3] file: Zero for block devices on old kernels

On 08/02/2018 02:05 PM, Nir Soffer wrote:
fallocate(FALLOC_FL_ZERO_RANGE) is supportd for block devices with
modern kernel, but when it is not, we fall back to manual zeroing.

Check if the underlying file is a block device when opening the file,
and fall back to ioctl(BLKZEROOUT) for aligned zero requests for a
block device.

+++ b/plugins/file/file.c
@@ -45,6 +45,7 @@
#if defined(__linux__) && !defined(FALLOC_FL_PUNCH_HOLE)
  #include <linux/falloc.h>   /* For FALLOC_FL_*, glibc < 2.18 */
+#include <linux/fs.h>       /* For BLKZEROOUT */

Will this pick up BLKZEROOUT in all cases where it is needed? Or do we need to relax the !defined(FALLOC_FL_PUNCH_HOLE), and just blindly include both of these headers for all Linux compilations?

+static bool
+is_aligned(struct handle *h, uint64_t n)
+  return n % h->sector_size == 0;

Since we know (but the compiler doesn't) that sector_size is a power of 2, it is slightly faster to use bitwise math:
 return !(n & (h->sector_size - 1))

+  if (h->is_block_device) {
+    if (ioctl (h->fd, BLKSSZGET, &h->sector_size)) {
+      nbdkit_error ("ioctl(BLKSSZGET): %s: %m", filename);
+      free (h);
+      return NULL;

If the ioctl() fails, would it be better to just fall back...

+    }
+  }
+  h->sector_size = 4096;  /* Safe guess */

...to the safe guess, instead of giving up entirely? (Might matter on a system with newer headers that have the macro, but where the kernel does not support the ioctl).

@@ -329,6 +361,20 @@ file_zero (void *handle, uint32_t count, uint64_t offset, int may_trim)
+  /* For aligned range and block devices, we can use BLKZEROOUT. */
+  if (h->is_block_device && is_aligned (h, offset) && is_aligned (h, count)) {

Since alignment is a power of 2, you can compress this as:

if (h->is_block_device && is_aligned (h, offset | count)) {

+    uint64_t range[2] = {offset, count};
+    r = ioctl (h->fd, BLKZEROOUT, &range);
+    if (r == 0)
+      return r;
+    nbdkit_error ("zero: %m");
+    return r;

Are we sure that treating ALL errors as fatal is worthwhile, or should we still attempt to trigger a fall back to writing?

+  }
    /* Trigger a fall back to writing */
    errno = EOPNOTSUPP;
    return r;

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

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