hmm, on Wed, Feb 02, 2011 at 10:24:55PM -0500, Nick Holland said that
> problems which are easy to fix.  Having worked with similar problems
> (and their recovery) on other OSs...ick.

talking about other OS's and risking making a fool of myself,
what do the others think about the new scheming fedora plans
to implement? [1]

disks have solved their ambiguity, DUID's are great.
a unique identifier is not necesseraly helpful for a nic
in this case however.

now, however <insert your opinion> that scheme might be,
there is a certain logic to it.  the physical placement
of the card (esp in the case of replacing a faulty one
is the ultimate word regarding that nic's role in the
given machine.

i always pereferred the openbsd naming to linux's
because one can put a "face" to the nic, it's not just eth[0-9].
it is esp. useful if cards are mixed in the box :]
(e.g. rl is outbound, re inbound, etc)



> A much better solution to your original problem would be to have spare
> parts on hand enabling you to replace the failed re0, in which case you

so it's not enough that you are in great stress because of the outage
and you need to replace the faulty card(s), you have to make sure
it uses the same driver as well? :]  i am sorry but this seams to me
as the parallel case of "policy problems shouldnt be solved in
software" applied here on the hardware.  the ideal state would be
just to replace the card and be done with it (of course this still
wouldn't work if an embedded nic needs replacing with an external one)


[1] http://digitizor.com/2011/01/25/fedora-15-network-device-naming/

-f
-- 
pain is inevitable, suffering is optional.

Reply via email to