aboutsummaryrefslogtreecommitdiff
path: root/block
diff options
context:
space:
mode:
authorThomas Huth <thuth@redhat.com>2021-05-27 19:20:19 +0200
committerKevin Wolf <kwolf@redhat.com>2021-06-02 14:23:20 +0200
commit73ebf29729d1a40feaa9f8ab8951b6ee6dbfbede (patch)
tree4ad2b9bc139e8368b56cc611e5f1b69cf14ab468 /block
parent260242a833d0cdfba5d9988169f2dc89946809a2 (diff)
block/file-posix: Fix problem with fallocate(PUNCH_HOLE) on GPFS
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>
Diffstat (limited to 'block')
-rw-r--r--block/file-posix.c11
1 files changed, 11 insertions, 0 deletions
diff --git a/block/file-posix.c b/block/file-posix.c
index 10b71d9a13..6e24083f3f 100644
--- a/block/file-posix.c
+++ b/block/file-posix.c
@@ -1650,6 +1650,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 {