Hello all, 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, //Jim 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 zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
