Jan Setje-Eilers wrote: >> On Tue, 2007-08-14 at 14:53 -0700, Jerry Gilliam wrote: >> >>> Peter Memishian has pointed out that the statement that >>> /etc/path_to_inst is a "pure cache" is not correct. >>> It is true that a functional instance file can be rebuilt >>> but solaris does rely on the instance number ordering >>> in the instance file not to change, otherwise devices >>> could be renumbered. Additions to the instance file >>> aren't necessary to boot, because the earlier version >>> must have been bootable too. And since changes are >>> cumulative, any additions in the updated file can be merged >>> without needing manual intervention. Hence a discrepancy >>> between the two instance files is not cause to invalidate >>> the archive. >>> >> I think it would be helpful to come up with a revision to section 6.6 >> which captures the higher-level requirement more crisply. >> >> I suspect that zpool.cache may be in much the same boat; as I understand >> it, it's not, strictly speaking a cache (if you blow it away, you have >> to re-import pools). I'd hope that it would be sufficient for the >> zpool.cache in the archive to describe the root pool (which at present >> is limited to a single mirror set), and that configuration for other >> pools could be pulled out of the actual copy in the root filesystem. >> > > I was lead to believe that zpool.cache will auto-magically be > re-built for non-root filesystems. > > For root filesystems, the kernel will need to learn how to mount root > without it (explicitly hunt for the device), otherwise we'll have a > lot of ugly failed to mount root failures, which are obviously a > serious issue. > > > Although we rely on zpool.cache now, we need to modify the early kernel code to cope if there isn't one. The identity of the pool being booted from is known to the booter (both GRUB and the OBP zfs booter) and is passed to the kernel. From that information, and the vdev label on the disk we're booted from, we should be able to initialize the root pool.
Lori
