yeahuh / rpms / qemu-kvm

Forked from rpms/qemu-kvm 2 years ago
Clone
6e7d01
From 8c339c3535728179acc94deb5b922aebcfac9ab6 Mon Sep 17 00:00:00 2001
6e7d01
From: Thomas Huth <thuth@redhat.com>
6e7d01
Date: Thu, 3 Jun 2021 16:13:34 -0400
6e7d01
Subject: [PATCH 2/4] block/file-posix: Fix problem with fallocate(PUNCH_HOLE)
6e7d01
 on GPFS
6e7d01
6e7d01
RH-Author: Thomas Huth <thuth@redhat.com>
6e7d01
Message-id: <20210603161334.607005-2-thuth@redhat.com>
6e7d01
Patchwork-id: 101673
6e7d01
O-Subject: [RHEL-8.5.0 qemu-kvm PATCH 1/1] block/file-posix: Fix problem with fallocate(PUNCH_HOLE) on GPFS
6e7d01
Bugzilla: 1944861
6e7d01
RH-Acked-by: Kevin Wolf <kwolf@redhat.com>
6e7d01
RH-Acked-by: Max Reitz <mreitz@redhat.com>
6e7d01
RH-Acked-by: Cornelia Huck <cohuck@redhat.com>
6e7d01
RH-Acked-by: Laszlo Ersek <lersek@redhat.com>
6e7d01
6e7d01
A customer reported that running
6e7d01
6e7d01
 qemu-img convert -t none -O qcow2 -f qcow2 input.qcow2 output.qcow2
6e7d01
6e7d01
fails for them with the following error message when the images are
6e7d01
stored on a GPFS file system :
6e7d01
6e7d01
 qemu-img: error while writing sector 0: Invalid argument
6e7d01
6e7d01
After analyzing the strace output, it seems like the problem is in
6e7d01
handle_aiocb_write_zeroes(): The call to fallocate(FALLOC_FL_PUNCH_HOLE)
6e7d01
returns EINVAL, which can apparently happen if the file system has
6e7d01
a different idea of the granularity of the operation. It's arguably
6e7d01
a bug in GPFS, since the PUNCH_HOLE mode should not result in EINVAL
6e7d01
according to the man-page of fallocate(), but the file system is out
6e7d01
there in production and so we have to deal with it. In commit 294682cc3a
6e7d01
("block: workaround for unaligned byte range in fallocate()") we also
6e7d01
already applied the a work-around for the same problem to the earlier
6e7d01
fallocate(FALLOC_FL_ZERO_RANGE) call, so do it now similar with the
6e7d01
PUNCH_HOLE call. But instead of silently catching and returning
6e7d01
-ENOTSUP (which causes the caller to fall back to writing zeroes),
6e7d01
let's rather inform the user once about the buggy file system and
6e7d01
try the other fallback instead.
6e7d01
6e7d01
Signed-off-by: Thomas Huth <thuth@redhat.com>
6e7d01
Message-Id: <20210527172020.847617-2-thuth@redhat.com>
6e7d01
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
6e7d01
(cherry picked from commit 73ebf29729d1a40feaa9f8ab8951b6ee6dbfbede)
6e7d01
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1944861
6e7d01
Signed-off-by: Thomas Huth <thuth@redhat.com>
6e7d01
Signed-off-by: Danilo C. L. de Paula <ddepaula@redhat.com>
6e7d01
---
6e7d01
 block/file-posix.c | 11 +++++++++++
6e7d01
 1 file changed, 11 insertions(+)
6e7d01
6e7d01
diff --git a/block/file-posix.c b/block/file-posix.c
6e7d01
index 62a463229f..371572f1b0 100644
6e7d01
--- a/block/file-posix.c
6e7d01
+++ b/block/file-posix.c
6e7d01
@@ -1587,6 +1587,17 @@ static int handle_aiocb_write_zeroes(void *opaque)
6e7d01
                 return ret;
6e7d01
             }
6e7d01
             s->has_fallocate = false;
6e7d01
+        } else if (ret == -EINVAL) {
6e7d01
+            /*
6e7d01
+             * Some file systems like older versions of GPFS do not like un-
6e7d01
+             * aligned byte ranges, and return EINVAL in such a case, though
6e7d01
+             * they should not do it according to the man-page of fallocate().
6e7d01
+             * Warn about the bad filesystem and try the final fallback instead.
6e7d01
+             */
6e7d01
+            warn_report_once("Your file system is misbehaving: "
6e7d01
+                             "fallocate(FALLOC_FL_PUNCH_HOLE) returned EINVAL. "
6e7d01
+                             "Please report this bug to your file sytem "
6e7d01
+                             "vendor.");
6e7d01
         } else if (ret != -ENOTSUP) {
6e7d01
             return ret;
6e7d01
         } else {
6e7d01
-- 
6e7d01
2.27.0
6e7d01