> 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. -jan
