All of lore.kernel.org
 help / color / mirror / Atom feed
From: Forza <forza@tnonline.net>
To: Joakim <ahoj79@gmail.com>, linux-btrfs@vger.kernel.org
Subject: Re: Speed up mount time?
Date: Wed, 23 Nov 2022 23:15:09 +0100 (GMT+01:00)	[thread overview]
Message-ID: <aff65aa.d623d93e.184a68f2476@tnonline.net> (raw)
In-Reply-To: <CAFka4xNPJby02JcK+immNU+AL6w-=iH7tNB4ZjULoYxnwG7U+Q@mail.gmail.com>



---- From: Joakim <ahoj79@gmail.com> -- Sent: 2022-11-23 - 13:33 ----

> I have a couple of machines (A and B) set up where each machine has a
> ~430 TB BTRFS subvolume, same data on both. Mounting these volumes
> with the following flags: noatime,compress=lzo,space_cache=v2
> 
> Initially mount times were quite long, about 10 minutes. But after i
> did run a defrag with -c option on machine B the mount time increased
> to over 30 minutes. This volume has a little over 100 TB stored.
> 
> How come the mount time increased by this?

You now have now extents to keep track of, which means more metadata to parse at mount. 

> 
> And is there any way to decrease the mount times? 10 minutes is long
> but acceptable, while 30 minutes is way too long.
> 
> Advice would be highly appreciated. :)
> 

You can defrag the subvolume and extent trees by using `btrfs fi defrag /path/to/subvol`. You can do this on each subvol and on the top level volume. This can reduce amounts of seeks, improving performance some. 

> 
> 
> Linux sm07b 5.4.17-2136.311.6.1.el8uek.x86_64 #2 SMP Thu Sep 22
> 19:29:28 PDT 2022 x86_64 x86_64 x86_64 GNU/Linux
> btrfs-progs v5.15.1
> Label: 'Storage'  uuid: 6ecd172e-3ebd-478c-9515-68162a41590d
>         Total devices 1 FS bytes used 105.04TiB
>         devid    1 size 436.57TiB used 107.87TiB path /dev/sdb
> 
> Data, single: total=107.34TiB, used=104.82TiB
> System, DUP: total=40.00MiB, used=11.23MiB
> Metadata, DUP: total=269.00GiB, used=221.57GiB
> GlobalReserve, single: total=512.00MiB, used=0.00B
> 
> [   51.764445] BTRFS info (device sdb): flagging fs with big metadata feature
> [   51.764450] BTRFS info (device sdb): use lzo compression, level 0
> [   51.764454] BTRFS info (device sdb): using free space tree
> [   51.764455] BTRFS info (device sdb): has skinny extents



  parent reply	other threads:[~2022-11-23 22:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-23 12:33 Speed up mount time? Joakim
2022-11-23 21:44 ` Qu Wenruo
2022-11-25  8:55   ` Joakim
2022-11-25  9:03     ` Qu Wenruo
2022-11-25  9:22       ` Joakim
2022-11-25 22:25         ` Torbjörn Jansson
2022-12-13  0:30       ` kenneth topp
2022-11-23 22:01 ` Roman Mamedov
2022-11-25  8:57   ` Joakim
2022-11-23 22:15 ` Forza [this message]
2022-11-25  8:58   ` Joakim

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=aff65aa.d623d93e.184a68f2476@tnonline.net \
    --to=forza@tnonline.net \
    --cc=ahoj79@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.