[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/2] block/file-posix: Fix problem with fallocate(PUNCH_HOLE)
From: |
Kevin Wolf |
Subject: |
Re: [PATCH 1/2] block/file-posix: Fix problem with fallocate(PUNCH_HOLE) on GPFS |
Date: |
Tue, 1 Jun 2021 13:35:10 +0200 |
Am 27.05.2021 um 19:20 hat Thomas Huth geschrieben:
> 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>
> ---
> block/file-posix.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/block/file-posix.c b/block/file-posix.c
> index 10b71d9a13..134ff01d82 100644
> --- a/block/file-posix.c
> +++ b/block/file-posix.c
> @@ -1650,6 +1650,16 @@ 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.");
This line is too long.
I've fixed it up and applied the series, thanks.
Kevin
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [PATCH 1/2] block/file-posix: Fix problem with fallocate(PUNCH_HOLE) on GPFS,
Kevin Wolf <=