On 02/03/11 14:14, frantisek holop wrote:
> 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]
too complex. And...at the moment, a one-trick pony (or more accurately,
a one-pony trick). We'll see if it gets adopted by the rest of the
Linux world, so it can be a LINUX way of doing things instead of a
single distro's way.
> disks have solved their ambiguity, DUID's are great.
> a unique identifier is not necesseraly helpful for a nic
> in this case however.
and in many cases, I think the DUIDs are too complex, too. Most of my
systems will continue to have disks which are identified only by sd0x or
wd0x. Where the DUIDs solve a problem (flash drives, my netbook which
backs up a "critical" directory to a SD flash card on boot, which may
"move" depending on what else is plugged into the machine), I'll happily
use them and be grateful for them, but I'm not going to replace
/dev/sd0a with 4b8432d7819c0c85.a just because I can, it has to improve
the system. 4b8432d7819c0c85 is completely non-intuitive, non-typeable
and non-memorable to me, and the ".a" at the end is too easy to lose in
the jumble. DUIDs have a definite cost. If it makes my life easier
(bootable flash drive, netbook backup thingie, some softraid configs),
great, I'll happily pay that cost, but not if I don't get a clear return.
> now, however <insert your opinion> that scheme might be,
> there is a certain logic to it.
absolutely.
just like the certain logic in the OpenBSD system or the MAC-tied system.
> 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.
unless, of course, you don't have the same card on the shelf, in which
case maybe you end up sticking a different card in a different slot
(i.e., replace a PCIe card with a PCI card) and then...back where we
were before.
OR...your replacement machine is a bit different than the production
machine.
Or it turns out the slot is bad on the machine. Or there's a cable in
the way that makes getting the card back in where the old one was
difficult. Or the case was causing the old card to pop out of the slot
and you figure you should move the card to another slot.
OpenBSD lets you get away with that pretty easily, especially if you
have different families of NICs in place, but things could move around
unpleasantly in the Fedora plan...after you were told that it wouldn't
happen and have no idea what to do when it does anyway.
Yes, my scenarios here violate my "have compatible spare hardware on
hand" rule. You were hoping to have a new job before it blew up on
you... :)
> 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)
yep. resorted to this more than once myself. Easier than reading my
hand-written MAC addresses on the spine of the card. :) Used to live by
it in the ISA days, as every NIC had its own rules for identifying (and
scarily enough, I knew most).
(and yes, I often catch myself doing the Ricer thing of trying to
optimize which NIC faces which network, even though in reality I know
neither will be nearly saturated, so the real world difference will be
absolutely zero)
>> 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? :]
well, yes, the idea of spare hardware is that it be swappable with the
failed hardware and Do The Job. But, if you widen the scope from
"compatible" to "sufficient to do the job with a bit of intervention",
then yes, you could have problems with OpenBSD here. Or Fedora, as
indicated above if your "sufficient" card requires installation into
another slot (planned or unplanned).
> 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)
If you are in great stress over an expected failure mode, you are doing
something wrong...and it happened long before the NIC failed. Hardware
fails. Be ready for it. Save stress for unexpected modes of failure
("uh... how did we not notice we were building the new data center
right under the executive kitchenette?" "You mean where the pipe just
failed?" "yeah, that one")
btw: my solution covers the on-board NIC failure, too -- that's covered
by replacing the whole computer, or at least the main board. When NICs
fail, they sometimes get really hot...the rest of the computer may not
be far behind the failed NIC chip. ALL hardware can fail. Be ready for it.
Hey, the Fedora plan solves a problem. The other linux "tied to MAC
address" system solves a different problem. The OpenBSD system solves
some problems. They all introduce certain OTHER problems. The OpenBSD
system is REALLY SIMPLE and easy to explain and easy to untangle when
things go wonky. I like that in a solution, as problems are often much
more complicated than people expect.
When NICs change in OpenBSD, I expect there to be (minor) issues, I fix
and move on. When NICs change in other systems which are supposed to
"save me" from the OpenBSD-style problems, I usually find my problem was
far more complicated than imagined by the developers, causing more delay
in recovery than I'd like. Hopefully, I've figured out how the other
systems work well in advance of The Event.
Nick.
