[Bug 251610] [patch] rc.d/zpool runs before ada(4) attaches
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 22 Dec 2021 10:18:32 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251610 --- Comment #3 from Hauke Fath <hf@spg.tu-darmstadt.de> --- Came here to say this. In the process of setting up a fileserver, I noticed that a 10 TB pool replicated from the old omniosce machine wouldn't mount during boot, while it had no problem when imported manually. My observations and comments: The (rather misleading) error message from /etc/rc.d/zpool is frequently interspersed with kernel autoconfiguration messages (see attachment). This made it harder than necessary to figure out what was going wrong, together with my disbelief that something so string-and-ducttape-y should be shipped in a release. Why does the kernel boot multi-user before it's done with autoconfiguration? And if parallelizing operations is the idea, why isn't there a barrier in place for things as vital as disk operations? Et c'est pas fini: Downstream, mountd is utterly confused about a list of mounts in /etc/zfs/exports that don't exist ("mountd[7977]: bad exports list line 'redacted': symbolic link in export path or statfs failed"). Why is this information persisted, instead of being created during the zpool import under /var/run - or not, if the pool isn't found? In the end, I inserted a 20 sec sleep in /etc/rc.d/zpool, and moved on, rather unimpressed. -- You are receiving this mail because: You are the assignee for the bug.