From: Nikolay Borisov <nborisov@suse.com>
To: "Wilson, Ellis" <ellisw@panasas.com>,
BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: BTRFS Mount Delay Time Graph
Date: Wed, 5 Dec 2018 08:55:59 +0200 [thread overview]
Message-ID: <558d3344-95de-da81-c385-a6623144d6ae@suse.com> (raw)
In-Reply-To: <a511850e-c08b-d6c5-0471-e523eff73680@panasas.com>
On 4.12.18 г. 22:14 ч., Wilson, Ellis wrote:
> On 12/4/18 8:07 AM, Nikolay Borisov wrote:
>> On 3.12.18 г. 20:20 ч., Wilson, Ellis wrote:
>>> With 14TB drives available today, it doesn't take more than a handful of
>>> drives to result in a filesystem that takes around a minute to mount.
>>> As a result of this, I suspect this will become an increasingly problem
>>> for serious users of BTRFS as time goes on. I'm not complaining as I'm
>>> not a contributor so I have no room to do so -- just shedding some light
>>> on a problem that may deserve attention as filesystem sizes continue to
>>> grow.
>> Would it be possible to provide perf traces of the longer-running mount
>> time? Everyone seems to be fixated on reading block groups (which is
>> likely to be the culprit) but before pointing finger I'd like concrete
>> evidence pointed at the offender.
>
> I am glad to collect such traces -- please advise with commands that
> would achieve that. If you just mean block traces, I can do that, but I
> suspect you mean something more BTRFS-specific.
A command that would be good is :
perf record --all-kernel -g mount /dev/vdc /media/scratch/
of course replace device/mount path appropriately. This will result in a
perf.data file which contains stacktraces of the hottest paths executed
during invocation of mount. If you could send this file to the mailing
list or upload it somwhere for interested people (me and perhaps) Qu to
inspect would be appreciated.
If the file turned out way too big you can use
perf report --stdio to create a text output and you could send that as
well.
>
> Best,
>
> ellis
>
next prev parent reply other threads:[~2018-12-05 6:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-03 18:20 BTRFS Mount Delay Time Graph Wilson, Ellis
2018-12-03 19:56 ` Lionel Bouton
2018-12-03 20:04 ` Lionel Bouton
2018-12-04 2:52 ` Chris Murphy
2018-12-04 15:08 ` Lionel Bouton
2018-12-03 22:22 ` Hans van Kranenburg
2018-12-04 16:45 ` [Mount time bug bounty?] was: " Lionel Bouton
2018-12-04 0:16 ` Qu Wenruo
2018-12-04 13:07 ` Nikolay Borisov
2018-12-04 13:31 ` Qu Wenruo
2018-12-04 20:14 ` Wilson, Ellis
2018-12-05 6:55 ` Nikolay Borisov [this message]
2018-12-20 5:47 ` Qu Wenruo
2018-12-26 3:43 ` Btrfs_read_block_groups() delay (Was Re: BTRFS Mount Delay Time Graph) Qu Wenruo
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=558d3344-95de-da81-c385-a6623144d6ae@suse.com \
--to=nborisov@suse.com \
--cc=ellisw@panasas.com \
--cc=linux-btrfs@vger.kernel.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).