linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
Cc: "Juan Simón" <decedion@gmail.com>, linux-btrfs@vger.kernel.org
Subject: Re: 48 seconds to mount a BTRFS hard disk drive seems too long to me
Date: Tue, 11 Jan 2022 17:13:34 +0100	[thread overview]
Message-ID: <20220111161334.GS14046@twin.jikos.cz> (raw)
In-Reply-To: <YdhzOhLar6TqZbbN@hungrycats.org>

On Fri, Jan 07, 2022 at 12:07:06PM -0500, Zygo Blaxell wrote:
> On Thu, Jan 06, 2022 at 04:48:21PM +0100, Juan Simón wrote:
> > Hard disk: 16TB SEAGATE IRONWOLF PRO 3.5", 7200 RPM 256MB CACHE
> > Arch Linux
> > Linux juan-PC 5.15.13-xanmod1-tt-1 #1 SMP Thu, 06 Jan 2022 12:14:06
> > +0000 x86_64 GNU/Linux
> > btrfs-progs v5.15.1
> > 
> > $ btrfs fi df /multimedia
> > Data, single: total=10.89TiB, used=10.72TiB
> > System, DUP: total=8.00MiB, used=1.58MiB
> > Metadata, DUP: total=15.00GiB, used=13.19GiB
> > GlobalReserve, single: total=512.00MiB, used=0.00B
> > 
> > I have formatted it as BTRFS and the mounting options (fstab) are:
> > 
> > /multimedia     btrfs
> > rw,noatime,autodefrag,compress-force=zstd,nossd,space_cache=v2    0 0
> > 
> > The disk works fine, I have not detected any problems but every time I
> > reboot the system takes a long time due to the mounting of this drive
> > 
> > $ systemd-analyze blame
> > 48.575s multimedia.mount
> > ....
> > 
> > I find it too long to mount a drive, is this normal, is it because of
> > one of the mounting options, or because of the size of the hard drive?
> 
> Worst-case, you'll need about one second of mounting time for every ~180
> block groups on a spinning disk, which works out to about 89 seconds on
> that drive when it's full.
> 
> It's a known issue, but it will require a disk format change to fix, so
> it will likely be rolled into a larger change set like extent tree v2.

Yeah, there was even a suggestion to add yet another tree to store the
block group information with better locality, this will be part of the
extent tree v2 update. Otherwise we can try to do readahead, there is
something already done I can't find right now.

      reply	other threads:[~2022-01-11 16:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-06 15:48 48 seconds to mount a BTRFS hard disk drive seems too long to me Juan Simón
2022-01-06 19:58 ` Chris Murphy
2022-01-06 23:17   ` Forza
2022-01-11 16:07   ` David Sterba
2022-01-07 17:07 ` Zygo Blaxell
2022-01-11 16:13   ` David Sterba [this message]

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=20220111161334.GS14046@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=ce3g8jdj@umail.furryterror.org \
    --cc=decedion@gmail.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).