From: Nir Soffer <nsoffer@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: QEMU Developers <qemu-devel@nongnu.org>,
qemu-block <qemu-block@nongnu.org>, Max Reitz <mreitz@redhat.com>
Subject: Re: [PATCH for-5.1 2/2] file-posix: Allow byte-aligned O_DIRECT with NFS
Date: Mon, 13 Jul 2020 19:29:26 +0300 [thread overview]
Message-ID: <CAMRbyysF1j7rA_7NqdUSvri9Tck9EcVbTStoDEZU3EFbf5+rVg@mail.gmail.com> (raw)
In-Reply-To: <20200710142149.40962-3-kwolf@redhat.com>
On Fri, Jul 10, 2020 at 5:22 PM Kevin Wolf <kwolf@redhat.com> wrote:
>
> Since commit a6b257a08e3 ('file-posix: Handle undetectable alignment'),
> we assume that if we open a file with O_DIRECT and alignment probing
> returns 1, we just couldn't find out the real alignment requirement
> because some filesystems make the requirement only for allocated blocks.
> In this case, a safe default of 4k is used.
>
> This is too strict NFS, which does actually allow byte-aligned requests
> even with O_DIRECT. Because we can't distinguish both cases with generic
> code, let's just look at the file system magic and disable
> s->needs_alignment for NFS. This way, O_DIRECT can still be used on NFS
> for images that are not aligned to 4k.
>
> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> ---
> block/file-posix.c | 26 +++++++++++++++++++++++++-
> 1 file changed, 25 insertions(+), 1 deletion(-)
>
> diff --git a/block/file-posix.c b/block/file-posix.c
> index 0c4e07c415..4e9dac461b 100644
> --- a/block/file-posix.c
> +++ b/block/file-posix.c
> @@ -62,10 +62,12 @@
> #include <sys/ioctl.h>
> #include <sys/param.h>
> #include <sys/syscall.h>
> +#include <sys/vfs.h>
> #include <linux/cdrom.h>
> #include <linux/fd.h>
> #include <linux/fs.h>
> #include <linux/hdreg.h>
> +#include <linux/magic.h>
> #include <scsi/sg.h>
> #ifdef __s390__
> #include <asm/dasd.h>
> @@ -300,6 +302,28 @@ static int probe_physical_blocksize(int fd, unsigned int *blk_size)
> #endif
> }
>
> +/*
> + * Returns true if no alignment restrictions are necessary even for files
> + * opened with O_DIRECT.
> + *
> + * raw_probe_alignment() probes the required alignment and assume that 1 means
> + * the probing failed, so it falls back to a safe default of 4k. This can be
> + * avoided if we know that byte alignment is okay for the file.
> + */
> +static bool dio_byte_aligned(int fd)
> +{
> +#ifdef __linux__
> + struct statfs buf;
> + int ret;
> +
> + ret = fstatfs(fd, &buf);
> + if (ret == 0 && buf.f_type == NFS_SUPER_MAGIC) {
> + return true;
> + }
> +#endif
> + return false;
> +}
> +
> /* Check if read is allowed with given memory buffer and length.
> *
> * This function is used to check O_DIRECT memory buffer and request alignment.
> @@ -631,7 +655,7 @@ static int raw_open_common(BlockDriverState *bs, QDict *options,
>
> s->has_discard = true;
> s->has_write_zeroes = true;
> - if ((bs->open_flags & BDRV_O_NOCACHE) != 0) {
> + if ((bs->open_flags & BDRV_O_NOCACHE) != 0 && !dio_byte_aligned(s->fd)) {
> s->needs_alignment = true;
I did not know we have needs_alignment. Isn't this the same as using
request_alignment = 1?
For example we can check if we are on NFS and avoid the fallback to max_align:
if (!bs->bl.request_alignment) {
int i;
size_t align;
buf = qemu_memalign(max_align, max_align);
for (i = 0; i < ARRAY_SIZE(alignments); i++) {
align = alignments[i];
if (raw_is_io_aligned(fd, buf, align)) {
/* Fallback to safe value. */
bs->bl.request_alignment = (align != 1) ? align : max_align;
break;
}
}
qemu_vfree(buf);
}
After this we will have correct bl.request_alignment and buf_align.
Hopefully this will not break code expecting request_alignment >= 512.
Assuming that needs_alignment is well tested, this patch may be safer.
Nir
> }
>
> --
> 2.25.4
>
next prev parent reply other threads:[~2020-07-13 16:32 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-10 14:21 [PATCH for-5.1 0/2] qemu-img convert: Fix abort with unaligned image size Kevin Wolf
2020-07-10 14:21 ` [PATCH for-5.1 1/2] block: Require aligned image size to avoid assertion failure Kevin Wolf
2020-07-10 14:37 ` Eric Blake
2020-07-13 11:19 ` Max Reitz
2020-07-13 11:52 ` Max Reitz
2020-07-13 14:29 ` Kevin Wolf
2020-07-14 9:56 ` Max Reitz
2020-07-14 11:08 ` Kevin Wolf
2020-07-14 16:22 ` Max Reitz
2020-07-15 9:20 ` Kevin Wolf
2020-07-13 16:33 ` Nir Soffer
2020-07-13 16:56 ` Kevin Wolf
2020-07-15 13:22 ` Nir Soffer
2020-07-15 13:42 ` Kevin Wolf
2020-07-15 14:03 ` Nir Soffer
2020-07-15 14:03 ` Daniel P. Berrangé
2020-07-10 14:21 ` [PATCH for-5.1 2/2] file-posix: Allow byte-aligned O_DIRECT with NFS Kevin Wolf
2020-07-10 14:39 ` Eric Blake
2020-07-13 16:29 ` Nir Soffer [this message]
2020-07-10 14:43 ` [PATCH for-5.1 0/2] qemu-img convert: Fix abort with unaligned image size no-reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMRbyysF1j7rA_7NqdUSvri9Tck9EcVbTStoDEZU3EFbf5+rVg@mail.gmail.com \
--to=nsoffer@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).