From: Dominique MARTINET <dominique.martinet@atmark-techno.com>
To: Pavel Tikhomirov <ptikhomirov@virtuozzo.com>,
Josef Bacik <josef@toxicpanda.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, 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, 5 Aug 2022 16:38:21 +0900 [thread overview]
Message-ID: <YuzI7Tqi3n+d+V+P@atmark-techno.com> (raw)
In-Reply-To: <YuwUw2JLKtIa9X+S@localhost.localdomain> <21dd32c6-f1f9-f44a-466a-e18fdc6788a7@virtuozzo.com>
Pavel Tikhomirov wrote on Thu, Aug 04, 2022 at 07:30:52PM +0300:
> I see a similar problem here
> https://lore.kernel.org/linux-btrfs/Yr4nEoNLkXPKcOBi@atmark-techno.com/#r ,
> but in my case I have "5.18.6-200.fc36.x86_64" fedora kernel which does not
> have 5ccc944dce3d ("filemap: Correct the conditions for marking a folio as
> accessed") commit, so it should be something else.
The root cause might be different but I guess they're related enough: if
fiemap gets faster enough even when the whole file is in cache I guess
that works for me :)
Josef Bacik wrote on Thu, Aug 04, 2022 at 02:49:39PM -0400:
> 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,
FWIW this patch does help a tiny bit, but I'm still seeing a huge
slowdown: with patch cp goes from ~600MB/s (55s) to 136MB/s (3m55s) on
the second run; and without the patch I'm getting 47s and 5m35
respectively so this has gotten a bit better but these must still be
cases running through the whole list (e.g. when not hitting a hole?)
My reproducer is just running 'cp file /dev/null' twice on a file with
194955 extents (same file with mixed compressed & non-compressed extents
as last time), so should be close enough to what Pavel was describing in
just much worse.
--
Dominique
next prev parent reply other threads:[~2022-08-05 7:38 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
2022-08-05 7:38 ` Dominique MARTINET [this message]
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=YuzI7Tqi3n+d+V+P@atmark-techno.com \
--to=dominique.martinet@atmark-techno.com \
--cc=alexander.mikhalitsyn@virtuozzo.com \
--cc=clm@fb.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).