linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 48 seconds to mount a BTRFS hard disk drive seems too long to me
@ 2022-01-06 15:48 Juan Simón
  2022-01-06 19:58 ` Chris Murphy
  2022-01-07 17:07 ` Zygo Blaxell
  0 siblings, 2 replies; 6+ messages in thread
From: Juan Simón @ 2022-01-06 15:48 UTC (permalink / raw)
  To: linux-btrfs

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?

Thanks in advance. Regards.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: 48 seconds to mount a BTRFS hard disk drive seems too long to me
  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
  1 sibling, 2 replies; 6+ messages in thread
From: Chris Murphy @ 2022-01-06 19:58 UTC (permalink / raw)
  To: Juan Simón; +Cc: Btrfs BTRFS

On Thu, Jan 6, 2022 at 8:48 AM Juan Simón <decedion@gmail.com> 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?

I think it's due to reading all the block group items which are buried
in the extent tree. And on large file systems with a large extent
tree, it results in a lot of random IO reads, so on spinning drives
you get a ton of latency hits for this search.

This thread discusses some of the details as it relates to zoned
devices, which have even longer mount times I guess. But the comments
about block groups and extent tree apply the same to non-zoned.
https://lore.kernel.org/linux-btrfs/CAHQ7scVGPAwEGQOq3Kmn75GJzyzSQ9qrBBZrHFu+4YWQhGE0Lw@mail.gmail.com/

The mount options you're using aren't causing the mount delay. But be
certain you really want autodefrag - it's designed for the desktop,
small databases used by desktops, web browsers, and the like. If you
use it with bigger and/or very busy databases, it just results in a
ton of I/O and can really slow things down rather than speed them up.
You're better off in such a use case with scheduled defragment on a
dir by dir basis, which you can do using the btrfsmaintenance
package's btrfs-defrag.timer and .service unit, which you can
customize. It's maintained by kdave, also maintainer of btrfs-progs.
https://github.com/kdave/btrfsmaintenance


--
Chris Murphy

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: 48 seconds to mount a BTRFS hard disk drive seems too long to me
  2022-01-06 19:58 ` Chris Murphy
@ 2022-01-06 23:17   ` Forza
  2022-01-11 16:07   ` David Sterba
  1 sibling, 0 replies; 6+ messages in thread
From: Forza @ 2022-01-06 23:17 UTC (permalink / raw)
  To: Chris Murphy, Juan Simón; +Cc: Btrfs BTRFS



---- From: Chris Murphy <lists@colorremedies.com> -- Sent: 2022-01-06 - 20:58 ----

> On Thu, Jan 6, 2022 at 8:48 AM Juan Simón <decedion@gmail.com> 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?
> 
> I think it's due to reading all the block group items which are buried
> in the extent tree. And on large file systems with a large extent
> tree, it results in a lot of random IO reads, so on spinning drives
> you get a ton of latency hits for this search.
> 
> This thread discusses some of the details as it relates to zoned
> devices, which have even longer mount times I guess. But the comments
> about block groups and extent tree apply the same to non-zoned.
> https://lore.kernel.org/linux-btrfs/CAHQ7scVGPAwEGQOq3Kmn75GJzyzSQ9qrBBZrHFu+4YWQhGE0Lw@mail.gmail.com/
> 
> The mount options you're using aren't causing the mount delay. But be
> certain you really want autodefrag - it's designed for the desktop,
> small databases used by desktops, web browsers, and the like. If you
> use it with bigger and/or very busy databases, it just results in a
> ton of I/O and can really slow things down rather than speed them up.
> You're better off in such a use case with scheduled defragment on a
> dir by dir basis, which you can do using the btrfsmaintenance
> package's btrfs-defrag.timer and .service unit, which you can
> customize. It's maintained by kdave, also maintainer of btrfs-progs.
> https://github.com/kdave/btrfsmaintenance
> 

It might be worth trying to defragment the extent tree of each subvolume by pointing btrfs defrag to the subvolume and not use the -r option. I don't think the btrfsmaintenance script does this.

# btrfs fi defragment /mnt/btrfs 
# btrfs fi defragment /mnt/btrfs/subvol_A
# btrfs fi defragment /mnt/btrfs/subvol_B
...

Read-only snapshots can't be defragmented this way. 



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: 48 seconds to mount a BTRFS hard disk drive seems too long to me
  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-07 17:07 ` Zygo Blaxell
  2022-01-11 16:13   ` David Sterba
  1 sibling, 1 reply; 6+ messages in thread
From: Zygo Blaxell @ 2022-01-07 17:07 UTC (permalink / raw)
  To: Juan Simón; +Cc: linux-btrfs

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.

> Thanks in advance. Regards.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: 48 seconds to mount a BTRFS hard disk drive seems too long to me
  2022-01-06 19:58 ` Chris Murphy
  2022-01-06 23:17   ` Forza
@ 2022-01-11 16:07   ` David Sterba
  1 sibling, 0 replies; 6+ messages in thread
From: David Sterba @ 2022-01-11 16:07 UTC (permalink / raw)
  To: Chris Murphy; +Cc: Juan Simón, Btrfs BTRFS

On Thu, Jan 06, 2022 at 12:58:58PM -0700, Chris Murphy wrote:
> On Thu, Jan 6, 2022 at 8:48 AM Juan Simón <decedion@gmail.com> 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?
> 
> I think it's due to reading all the block group items which are buried
> in the extent tree. And on large file systems with a large extent
> tree, it results in a lot of random IO reads, so on spinning drives
> you get a ton of latency hits for this search.
> 
> This thread discusses some of the details as it relates to zoned
> devices, which have even longer mount times I guess. But the comments
> about block groups and extent tree apply the same to non-zoned.
> https://lore.kernel.org/linux-btrfs/CAHQ7scVGPAwEGQOq3Kmn75GJzyzSQ9qrBBZrHFu+4YWQhGE0Lw@mail.gmail.com/

That's unrelated to the problem on zoned drives, the delay there is
caused by time spent on reading the zone information.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: 48 seconds to mount a BTRFS hard disk drive seems too long to me
  2022-01-07 17:07 ` Zygo Blaxell
@ 2022-01-11 16:13   ` David Sterba
  0 siblings, 0 replies; 6+ messages in thread
From: David Sterba @ 2022-01-11 16:13 UTC (permalink / raw)
  To: Zygo Blaxell; +Cc: Juan Simón, linux-btrfs

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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2022-01-11 16:14 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 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).