All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>, qemu-block@nongnu.org
Cc: qemu-devel@nongnu.org, mreitz@redhat.com
Subject: Re: [PATCH for-5.1] file-posix: Mitigate file fragmentation with extent size hints
Date: Tue, 7 Jul 2020 09:47:06 -0500	[thread overview]
Message-ID: <7080e331-fa75-bc5c-1406-e4a772411ea2@redhat.com> (raw)
In-Reply-To: <20200707142329.48303-1-kwolf@redhat.com>

On 7/7/20 9:23 AM, Kevin Wolf wrote:
> Espeically when O_DIRECT is used with image files so that the page cache

Especially

> indirection can't cause a merge of allocating requests, the file will
> fragment on the file system layer, with a potentially very small
> fragment size (this depends on the requests the guest sent).
> 
> On Linux, fragmentation can be reduced by setting an extent size hint
> when creating the file (at least on XFS, it can't be set any more after
> the first extent has been allocated), basically giving raw files a
> "cluster size" for allocation.
> 
> This adds an create option to set the extent size hint, and changes the
> default from not setting a hint to setting it to 1 MB. The main reason
> why qcow2 defaults to smaller cluster sizes is that COW becomes more
> expensive, which is not an issue with raw files, so we can choose a
> larger file. The tradeoff here is only potentially wasted disk space.
> 
> For qcow2 (or other image formats) over file-posix, the advantage should
> even be greater because they grow sequentially without leaving holes, so
> there won't be wasted space. Setting even larger extent size hints for
> such images may make sense. This can be done with the new option, but
> let's keep the default conservative for now.
> 
> The effect is very visible with a test that intentionally creates a
> badly fragmented file with qemu-img bench (the time difference while
> creating the file is already remarkable) and then looks at the number of
> extents and the take a simple "qemu-img map" takes.

Cool!

> 
> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> ---
>   qapi/block-core.json      | 11 ++++++----
>   include/block/block_int.h |  1 +
>   block/file-posix.c        | 42 +++++++++++++++++++++++++++++++++++++++
>   3 files changed, 50 insertions(+), 4 deletions(-)
> 

> +#ifdef FS_IOC_FSSETXATTR
> +    /*
> +     * Try to set the extent size hint. Failure is not fatal, and a warning is
> +     * only printed if the option was explicitly specified.
> +     */
> +    {
> +        struct fsxattr attr;
> +        result = ioctl(fd, FS_IOC_FSGETXATTR, &attr);
> +        if (result == 0) {
> +            attr.fsx_xflags |= FS_XFLAG_EXTSIZE;
> +            attr.fsx_extsize = file_opts->extent_size_hint;
> +            result = ioctl(fd, FS_IOC_FSSETXATTR, &attr);
> +        }
> +        if (result < 0 && file_opts->has_extent_size_hint) {
> +            warn_report("Failed to set extent size hint: %s",
> +                        strerror(errno));
> +        }
> +    }
> +#endif

That's a neat ioctl to learn.

Reviewed-by: Eric Blake <eblake@redhat.com>

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



  reply	other threads:[~2020-07-07 14:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-07 14:23 [PATCH for-5.1] file-posix: Mitigate file fragmentation with extent size hints Kevin Wolf
2020-07-07 14:47 ` Eric Blake [this message]
2020-07-07 16:17 ` Kevin Wolf
2020-07-10 16:12   ` Max Reitz
2020-07-13  9:08     ` Max Reitz
2020-07-13 13:12       ` Kevin Wolf
2020-07-13 13:45         ` Kevin Wolf

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=7080e331-fa75-bc5c-1406-e4a772411ea2@redhat.com \
    --to=eblake@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.