From: Wang Yugui <wangyugui@e16-tech.com>
To: Josef Bacik <josef@toxicpanda.com>
Cc: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>,
Chris Mason <clm@fb.com>, David Sterba <dsterba@suse.com>,
linux-btrfs@vger.kernel.org, lkml <linux-kernel@vger.kernel.org>,
Chen Liang-Chun <featherclc@gmail.com>,
Alexander Mikhalitsyn <alexander.mikhalitsyn@virtuozzo.com>,
kernel@openvz.org,
Dominique MARTINET <dominique.martinet@atmark-techno.com>,
Yu Kuai <yukuai3@huawei.com>, Theodore Ts'o <tytso@mit.edu>
Subject: Re: fiemap is slow on btrfs on files with multiple extents
Date: Fri, 05 Aug 2022 12:52:32 +0800 [thread overview]
Message-ID: <20220805125231.9327.409509F4@e16-tech.com> (raw)
In-Reply-To: <YuwUw2JLKtIa9X+S@localhost.localdomain>
Hi,
> On Thu, Aug 04, 2022 at 07:30:52PM +0300, Pavel Tikhomirov wrote:
> > I ran the below test on Fedora 36 (the test basically creates "very" sparse
> > file, with 4k data followed by 4k hole again and again for the specified
> > length and uses fiemap to count extents in this file) and face the problem
> > that fiemap hangs for too long (for instance comparing to ext4 version).
> > Fiemap with 32768 extents takes ~37264 us and with 65536 extents it takes
> > ~34123954 us, which is x1000 times more when file only increased twice the
> > size:
> >
>
> Ah that was helpful, thank you. I think I've spotted the problem, please give
> this a whirl to make sure we're seeing the same thing. Thanks,
>
> Josef
This patch improve the performance very well, but it seems to break
xfstest generic/285.
xfstest generic/285:
06.11 SEEK_HOLE expected 8192 or 16384, got 8191. FAIL
06.12 SEEK_DATA expected 8191 or 8191, got 12288. FAIL
06.23 SEEK_HOLE expected 16384 or 16384, got 16383. FAIL
06.24 SEEK_DATA expected 16383 or 16383, got -1. FAIL
Best Regards
Wang Yugui (wangyugui@e16-tech.com)
2022/08/05
>
> From 1133d5ebf952ebf334bc7be21a575b1f52eb71d4 Mon Sep 17 00:00:00 2001
> Message-Id: <1133d5ebf952ebf334bc7be21a575b1f52eb71d4.1659638886.git.josef@toxicpanda.com>
> From: Josef Bacik <josef@toxicpanda.com>
> Date: Thu, 4 Aug 2022 14:45:53 -0400
> Subject: [PATCH] btrfs: don't search entire range for delalloc with fiemap
>
> For the case where we have
>
> [EXTENT1][HOLE][EXTENT2]
>
> If we fiemap from [HOLE] we will search to len (which could be -1) to
> see if there's any delalloc extents in the range, however in the above
> case btrfs_get_extent() returns a hole em for just the range of the
> hole, as it will find EXTENT2, so all we need to do is search for
> delalloc in the hole range, not the entire rest of the requested fiemap
> range.
>
> This fixes the extremely bad fiemap performance with very large sparse
> files.
>
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> ---
> fs/btrfs/inode.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
> index 8fc1e3b6e00c..b7ad8f7a7b53 100644
> --- a/fs/btrfs/inode.c
> +++ b/fs/btrfs/inode.c
> @@ -7095,7 +7095,7 @@ struct extent_map *btrfs_get_extent_fiemap(struct btrfs_inode *inode,
> hole_em = em;
>
> /* check to see if we've wrapped (len == -1 or similar) */
> - end = start + len;
> + end = em->start + em->len;
> if (end < start)
> end = (u64)-1;
> else
> --
> 2.36.1
next prev parent reply other threads:[~2022-08-05 4:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-04 16:30 fiemap is slow on btrfs on files with multiple extents Pavel Tikhomirov
2022-08-04 18:49 ` Josef Bacik
2022-08-05 4:52 ` Wang Yugui [this message]
2022-08-05 7:38 ` Dominique MARTINET
2022-08-05 9:54 ` Filipe Manana
2022-09-01 13:25 ` Filipe Manana
2022-09-01 15:06 ` Pavel Tikhomirov
2022-09-21 7:30 ` Dominique MARTINET
2022-09-21 9:00 ` Filipe Manana
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=20220805125231.9327.409509F4@e16-tech.com \
--to=wangyugui@e16-tech.com \
--cc=alexander.mikhalitsyn@virtuozzo.com \
--cc=clm@fb.com \
--cc=dominique.martinet@atmark-techno.com \
--cc=dsterba@suse.com \
--cc=featherclc@gmail.com \
--cc=josef@toxicpanda.com \
--cc=kernel@openvz.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ptikhomirov@virtuozzo.com \
--cc=tytso@mit.edu \
--cc=yukuai3@huawei.com \
/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).