On 03/05/2023 21:56, Nicholas D Steeves wrote:
> Hi,
>
> Graham Cobb <g+deb...@cobb.uk.net> writes:
>
>> The new checks at mount time cause mount times for large filesystems to be
>> much
>> longer. My roughly 10TB filesystem now takes over 90 seconds to mount.
>>
More recent kernels have definitely improved the situation. My largest
filesystem now takes about 60 seconds to mount at boot, although I have
not checked how long it takes if it was not cleanly unmounted.
> I'm curious how "aged" the fs is, (largest generation from btrfs subvol
> list), how many subvolumes, if qgroups are used, raid56, are reflink
> copies of large trees regularly made, deduplication, compression, etc.
Some info on this filesystem:
This is an online backup disk (btrbk). It stores snapshots. Lots of
them. From many different systems. It is btrfs-over-lvm-over-luks. Data
is Single; Metadata is RAID1. There are two disks, each has an LV on a
VG on a LUKS volume.
# btrfs fi usage /mnt/snapshots/
Overall:
Device size: 18.00TiB
Device allocated: 15.22TiB
Device unallocated: 2.77TiB
Device missing: 0.00B
Device slack: 0.00B
Used: 15.10TiB
Free (estimated): 2.88TiB (min: 1.49TiB)
Free (statfs, df): 2.88TiB
Data ratio: 1.00
Metadata ratio: 2.00
Global reserve: 512.00MiB (used: 0.00B)
Multiple profiles: no
Data,single: Size:15.01TiB, Used:14.90TiB (99.29%)
/dev/mapper/cryptdata16tb2--vg-backupsnapshot 10.52TiB
/dev/mapper/cryptbackup16tb--vg-backupsnapshot 4.49TiB
Metadata,RAID1: Size:110.00GiB, Used:103.12GiB (93.74%)
/dev/mapper/cryptdata16tb2--vg-backupsnapshot 110.00GiB
/dev/mapper/cryptbackup16tb--vg-backupsnapshot 110.00GiB
System,RAID1: Size:32.00MiB, Used:1.80MiB (5.62%)
/dev/mapper/cryptdata16tb2--vg-backupsnapshot 32.00MiB
/dev/mapper/cryptbackup16tb--vg-backupsnapshot 32.00MiB
Unallocated:
/dev/mapper/cryptdata16tb2--vg-backupsnapshot 1.37TiB
/dev/mapper/cryptbackup16tb--vg-backupsnapshot 1.40TiB
Some answers to your questions:
I'm curious how "aged" the fs is, (largest generation from btrfs subvol
list) -- 1248641
how many subvolumes -- 1810
if qgroups are used -- no
raid56 -- no - single data, raid1 metadata
are reflink copies of large trees regularly made -- yes (btrbk)
deduplication -- no
compression, etc. -- some
Note: there are two other btrfs filesystems on this system.
Same approach (btrfs-over-lvm-over-luks). Similar disks.
Both are around 6-8 TB. These mount much more quickly.
The main difference is they do not have anything like the number of
subvolumes, nor the continuous creation and deletion of subvolumes that
this backup disk has.
> I've updated the btrfs page on wiki.debian.org with your report and
> suggested workaround, and I'd like to provide more context to not scare
> people off btrfs. Ie, as Adam said, it's not normal for mount to take
> this long.
I think the way to frame this is not that it is a problem people are
likely to see, but that if they find themselves in that situation, the
answer is simple: add x-systemd.mount-timeout=180s (and consider adding
nofail).
I will try to take a look at the wiki in the next few days.
