Re: Ethernet interface numbering in etch
On Tue, Mar 27, 2007 at 12:06:09AM -0400, Nathanael Nerode wrote:
> After writing a very long message, I realize that there was a much simpler
> solution, so if you want to cut to the chase, skip to the end!
> Steve Langasek wrote:
> >Which do you think is the common case -- a system with more than one network
> >interface where it's necessary to preserve interface ordering across
> >reboots, or a system where the admin will frequently change out the network
> >hardware and need to reuse the same interface names?
> I would guess the second, or more specifically I would guess that in any given
> month,
> - (the total number of instances of admins swapping out network hardware and
> needing to reuse the same interface names)
> is greater than
> - (the total number of instances of admins setting up new systems with more than
> one interface where it's necessary to preserve interface ordering across
> reboots)
That's not a proper comparison. A proper comparison would be between the
number of instances of admins swapping out network hardware and needing to
reuse the same interface names, and the number of admins *rebooting* systems
with more than one interface.
> * Most machines have only one interface (If Debian is running on more
> routers than workstations, obviously this would be wrong, but I doubt
> that's the case.)
Lots of systems have multiple interfaces without being routers. Servers are
likely to have multiple interfaces for load balancing and/or redundancy;
firewalls (which may or may not be included in what you mean by "routers")
will have multiple interfaces that it may be *very* important to keep
straight. So yeah, based on my own experience, I disagree with you about
which is the common case.
> Also, there's another argument for defaulting to case two.
> * Setup for case one needs only needs to be done (worst case) at the
> first reboot,
Well, no, it needs to be done on the first reboot when the device names
change, which could be at any point where extensive downtime is not
otherwise expected/allowable. (Sure, you may be swapping out hardware
because of an unplanned failure, but at least then pain is somewhat
expected...)
> (1) Hardware which exists is assigned a static name, and keeps it;
> (2) When the hardware stops existing, the name is released for reuse;
Er, that's not meaningful. udev doesn't know the difference between
"hardware stops existing" and "hardware is slow to become available to
udev".
> To be more specific about how this would work, network interface naming would
> be a two-stage process, with all "new" interfaces delayed until after all "old"
> interfaces were believed to be up.
> (1) When a "new" interface shows up which doesn't have a static name assigned yet,
> delay naming it until you believe all the "old" interfaces which do have
> a static name assigned are up.
> (2) When all the interfaces with static names assigned are believed to be up
> (enough time has passed), assign static names to the "new" interfaces,
> starting with the first unused one, even if it was previously assigned to
> some interface which no longer exists (didn't come up).
That's a race condition, basically, regardless of timeout length; good luck
convincing the udev maintainer that this is a good idea.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Reply to: