(Sorry for the delay -- I investigated the cause but somehow failed to post here. Recently someone on the mailing list reported it also, with same conclusion.)
On Tue, Mar 31, 2020 at 01:20:48PM +0100, Graham Cobb wrote: > Package: btrfs-progs > Version: 5.3.1-1 > 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. 90 seconds for 10TB sounds like something is terribly wrong in your case. I currently have only one spinning rust array, of 3 disks 7TB, and it completes mount in around a second. But, there are folks with massive arrays with mount times of several minutes or tent of minutes, so the issue is real. > Unfortunately, this is longer than the default systemd mount timer and systemd > assumes the mount has failed (and, in fact, cancels it). If the mount is not > marked with "nofail" this causes boot to fail and to drop into the rescue > console. How can a mount be "cancelled"? The syscall provides no way to abort a mount attempt -- it either succeeds or fails, with no possible timeouts on userspace side. I'm not experienced at debugging systemd issues, but it appears to me that systemd has a separate thread doing the mount() call, reports timeout despite the call being still in progress, then upon successful mount _unmounts_ the filesystem again. From: Christoph Anton Mitterer <cales...@scientia.net> } We see that, too, at the institute... any larger (few TB) filesystems } in /etc/fstab make systemd cause the system to fail at boot... leaving } it a state with no remote resuce (ssh) being possible. } } Since such filesystems would mount just fine... I would rather say that } this functionality is a severe bug. They do mount successfully with a manual mount, so do they with initscripts. The timeout is done on systemd side, with the kernel doing as expected. Also, it can't be fixed in btrfs-progs, as no code in this package is run at mount time. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. ⢿⡄⠘⠷⠚⠋⠀ -- <willmore> on #linux-sunxi ⠈⠳⣄⠀⠀⠀⠀
