> > 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.
The only place these instance numbers are actually exposes is in network drivers. The fact that they are exposed there is a long standing miss-architecture that will eventually (no immediate cut- over due to compat. issues) be addressed by clearview. I had in fact prototyped a re-merge of an out of date path_to_inst during boot, but was encouraged not to put that back with the archive check changes since the only exposed issue this addresses is dr-ing in more than one nic of the same flavor and then rebooting without syncing the archive while caring which nic was which (not ipmp or an aggr). While this situation is real, it is at least somewhat contrived and the additional complexity of the re-merge didn't seem like something we'd want to take give that another project was going to eliminate the exposure entirely. I'm still open to putting this back in, but we should feel like it's something we'll want to keep around moving forward or just a temporary bug fix. > 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. Correct. -jan
