On Fri, Jul 31, 2015 at 10:44 AM, Duncan <1i5t5.dun...@cox.net> wrote: > For the specific case of systemd giving up on many-device btrfs mounts, > now that I've read a bit more and am thinking in terms of dropins, I'd > guess the following option, covered in systemd.mount and to be placed in > the mount section with an appropriate value, should do it: > > TimeoutSec= > > The default timeoutsec setting is set in /etc/systemd/systemd.conf > (systemd-system.conf manpage) as DefaultTimeoutStartSec=, with 90 seconds > the shipped default if it's not set there. Without a specific setting in > the unit file, that system default would be used.
I'l like to stress the fact that all those timeouts were well beyond the time it took to mount the btrfs raid manually (when it happened to me, a long time ago - might be a different story for Vincent). Mounting it manually did take a couple of seconds, but less then 10 seconds, which isn't even close to 30, let alone 90 seconds. In fact, I believe it was less than 5 seconds and as far as I remember, the fs would sometimes even be mounted for this very short time and then (after those few seconds) systemd would unmount it. This is something that doesn't add up in my mind, because all those default timeout values look okay to me, but somehow, mounts appear to time out before the time is actually up. In other words - I have never waited 30 seconds or longer for a btrfs mount to complete, yet I apparently hit a 90 second timeout if TimeoutSec was the culprit. (However, again, this was my case - not sure if Vincent may be hitting a different issue.) -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
