> One scenario I've seen discussed is to create one-port aggregations when > the admin suspects he will need to increase the bandwidth in the future > and doesn't want to adjust the network configuration at that time (e.g., > no need to transition from e1000g2 -> aggr3). Of course, with vanity > naming that should no longer be an issue. > Yes.
But I still don't see then answer of my original question. It seems delete-xxx -t is not very much useful, and "link down" cannot fully replace "delete-xxx -t". I guess I will just leave "delete-xxx -t" as is. > The DR-capable machines I've seen have a sticker on the inside of the > cabinet that gives the mapping between those paths (without the leading > /devices part) and the slot numbers. "cfgadm -v" also provides that > translation. > How that sticker predict what instance number the software assigns for a device? and it seems that cfgadm -v only report the mapping between Ap_Id to /devices path. That won't be changed. But I agree that after vanity naming, it is not obvious of mapping between the Ap_Id to the link vanity name. Maybe I should somehow add an option to show-phys to show the device path of a physical device? > > > I think it's still worthwhile, though we might want to do it after the > > > initial putback. For instance, we could do: > > > > > > * Initial putback: compatible names by default; no change to > > > di_walk_minor(). > > > * Follow-up putback: change di_walk_minor(); examine and address > > > impact. > > > * Follow-up putback #2: vanity names by default; examine and > > > address impact. > > > > > If so, do we need to mention this phases plan in the PSARC document? > > I'd think so. > My concern is: This is only a tentative plan. Does writing it in the PSARC document makes it as a commitment? Thanks - Cathy
