I have one more thought - or a question - about the current
strangeness of rpool import: is it supported, or does it work,
to have rpools on multipathed devices?
If yes (which I hope it is, but don't have a means to check)
what sort of a string is saved into the pool's labels as its
device path? Some metadevice which is on a layer above mpxio,
or one of the physical storage device paths? If the latter is
the case, what happens during system boot if the multipathing
happens to choose another path, not the one saved in labels?
Thanks for insights,
2012-10-03 13:54, Jim Klimov wrote:
So the basic question is: WHY does the OS want to use the
device path (/pci... string) coded into the rpool's vdevs
mid-way in the bootup during vfs root-import routine, and
fail with a panic if the device naming changed, when the
loader (GRUB) for example already had no problem reading
the same rpool? Is there any rationale or historic baggage
to this situation? Is it a design error or shortsight?
Isn't it possible to use the same routine as for other
pool imports, including import of this same rpool from a
live-media boot - just find the component devices (starting
with the one passed by the loader and/or matching by pool
name and/or GUID) and import the resulting pool? Perhaps,
this could be attempted if the current method fails, before
reverting to a kernel panic - try another method first.
zfs-discuss mailing list