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. > 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. 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. Christoph Anton Mitterer <cales...@scientia.net> writes: > 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. I'm also curious about if there are any factors here that are causing the failure. If this is truly typical btrfs+systemd scaling problem then, yes, it's unconscionable to pretend that everything is ok...and it at least needs to be documented. Please feel free to contribute to the wiki.debian.org page, by the way! Adam Borowski <kilob...@angband.pl> writes: > 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. Hm, yes, I agree this sounds odd, but Fedora 33 shipped with btrfs by default in Oct 2020, and has stayed with that default, so I wonder if this bug was fixed in systemd by then? If not, I wonder if we're "doing things differently", so to speak, and triggering a bug that they're not (initramfs vs dracut, etc). Cheers, Nicholas
signature.asc
Description: PGP signature
