[Bug 251610] [patch] rc.d/zpool runs before ada(4) attaches

From: <bugzilla-noreply_at_freebsd.org>
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.