| Message ID | 20210527172020.847617-2-thuth@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Improve the fallocate() EINVAL in handle_aiocb_write_zeroes() | expand |
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
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."); } else if (ret != -ENOTSUP) { return ret; } else {
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(+)