Re: Large multi-device BTRFS array (usually) fails to mount on boot.

["Joshua" <joshua@mailmag.net>]

February 3, 2021 3:16 PM, "Graham Cobb" <g.btrfs@cobb.uk.net> wrote:

> On 03/02/2021 21:54, joshua@mailmag.net wrote:
> 
>> Good Evening.
>> 
>> I have a large BTRFS array, (14 Drives, ~100 TB RAW) which has been having problems mounting on
>> boot without timing out. This causes the system to drop to emergency mode. I am then able to mount
>> the array in emergency mode and all data appears fine, but upon reboot it fails again.
>> 
>> I actually first had this problem around a year ago, and initially put considerable effort into
>> extending the timeout in systemd, as I believed that to be the problem. However, all the methods I
>> attempted did not work properly or caused the system to continue booting before the array was
>> mounted, causing all sorts of issues. Eventually, I was able to almost completely resolve it by
>> defragmenting the extent tree and subvolume tree for each subvolume. (btrfs fi defrag
>> /mountpoint/subvolume/) This seemed to reduce the time required to mount, and made it mount on boot
>> the majority of the time.
> 
> Not what you asked, but adding "x-systemd.mount-timeout=180s" to the
> mount options in /etc/fstab works reliably for me to extend the timeout.
> Of course, my largest filesystem is only 20TB, across only two devices
> (two lvm-over-LUKS, each on separate physical drives) but it has very
> heavy use of snapshot creation and deletion. I also run with commit=15
> as power is not too reliable here and losing power is the most frequent
> cause of a reboot.

Thanks for the suggestion, but I have not been able to get this method to work either.

Here's what my fstab looks like, let me know if this is not what you meant!

UUID={snip} /         ext4  errors=remount-ro 0 0
UUID={snip} /mnt/data btrfs defaults,noatime,compress-force=zstd:2,x-systemd.mount-timeout=300s 0 0

However, the system still fails to mount in less than 5 minutes, and drops to emergency mode.
Upon checking dmesg logs, it is clear the system is only wait 120 seconds, before giving up on mounting, and dropping to emergency mode.

--Joshua