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