From: Josef Bacik <josef@toxicpanda.com>
To: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>
Cc: 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: Thu, 4 Aug 2022 14:49:39 -0400 [thread overview]
Message-ID: <YuwUw2JLKtIa9X+S@localhost.localdomain> (raw)
In-Reply-To: <21dd32c6-f1f9-f44a-466a-e18fdc6788a7@virtuozzo.com>
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
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-04 18:49 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 [this message]
2022-08-05 4:52 ` Wang Yugui
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=YuwUw2JLKtIa9X+S@localhost.localdomain \
--to=josef@toxicpanda.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=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