Jan Setje-Eilers 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. > > 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.
The Clearview project doesn't completely remove that particular bit of mis-architecture. It just makes the impact less disastrous to administrators. The Clearview UV component legitimizes the administrative object which is the datalink, and allows the administrator to give that object a meaningful name (e.g., please give the name "isp3" to the datalink over the bge0 device) There is a device under that datalink, and that device name is still at the mercy of path_to_inst. If path_to_inst is munged in such a way that what used to be "bge0" is now "bge2", then an administrator will need to re-associate the "isp3" datalink with the proper device by renaming links (i.e., manually using dladm(1M) rename-link commands). As a result I would say that path_to_inst is still a crucial piece of system state during boot even after 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. Would it always be safe to use the /etc/path_to_inst file in the / filesystem as is being proposed for editable files and driver.conf files? > 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. If we can read the file that's in the filesystem, then I don't see the need for the re-merge. -Seb
