> > Or one could just temporarily remove that link from the aggregation and > > plumb it, right? > > Only if this link is not the only port in the aggregation. But in most > cases, yes. And I don't know why create an aggregation with a single port in > the first place.
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. > > > Will we add this support? and how? In the form of a linkprop? > > > > To me, this still feels like unrelated work. > > I agree. I think the comments originated from that user cannot tell the > /devices path from the link name, but as there is no directly relationship > between the /devices path and the physical slot number, I don't understad > why /devices path is important. 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. > > 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. -- meem
