ZFSPoolActivationII written at 01:07:20; Add Comment
ZFS pool activation and iSCSI (part II)
Here's an interesting question that should have occurred to me much earlier:
At the SMF level, the iSCSI initiator is svc:/network/iscsi/initiator.
Nothing explicitly depends on it (at least according to '
(A great deal of SMF is opaque, annoying, or both.)
Now it's time for theorizing.
If we take SMF at its word, there is no explicit ordering dependency
in SMF. Any ordering we get is either a lucky coincidence or enforced
by something else, and I don't believe it's a lucky coincidence. The
obvious candidate to enforce an ordering is the kernel, since it
handles both the iSCSI and ZFS parts of all of this. It would make a
kind of sense if the kernel delayed ZFS pool activation until iSCSI
discovery had finished; it's very analogous to how kernels often delay
things for SCSI disk discovery. Given that iSCSI disk discovery can be
quite protracted, it would also make sense if at some point a clever
Sun kernel developer broke that absolute dependency so that the boot
could still proceed even if iSCSI discovery was taking ages; such a
dependency break would match the symptoms we saw here, where '
(Since Oracle no longer updates the OpenSolaris source code it's impossible to verify this theory. Besides, my patience for spelunking Solaris kernel code is pretty close to being exhausted.)
* * *
Atom feeds are available; see the bottom of most pages.