Re: Question to new network device names
On Thu, Aug 24, 2017 at 08:30:33AM -0500, Dave Sherohman wrote:
> On Thu, Aug 24, 2017 at 09:17:00AM -0400, The Wanderer wrote:
> > However, I'll point out that machines with this many network interfaces
> > are *by far* the exception rather than the rule; indeed, even machines
> > with more than *one* interface each of wired and wireless are reasonably
> > rare.
>
> In the home desktop space, perhaps. When you deal with rackmount
> servers, OTOH, four (wired) network ports is pretty standard these days.
>
> Of course, they're all on the same bus and using identical hardware/
> firmware, so the "order might change based on which drivers load first"
> case still doesn't apply.
>
> > To the best of my awareness, the rationale for calling this "predictable
> > network interface names" is that, on a single computer which has
> > multiple network interfaces of a given type, this naming scheme makes
> > it possible to predict *from one boot to the next* what the name of each
> > one will be. On such a computer, this is extremely valuable.
> >
> > By contrast, on a computer which has at most one interface of a given
> > type, this naming scheme provides - so far as I can tell - no advantage
> > at all.
> >
> > What's more, when working on *multiple* computers of that latter type,
> > this naming scheme makes it impossible to predict *from one computer to
> > the next* what the name of the sole available interface will be.
> >
> > As such, IMO this naming scheme makes network-interface names
> > significantly *less* predictable in the real-world scenario which is
> > most commonly encountered.
>
> This closely parallels the move from using /dev/sdXn to UUIDs for
> referring to filesystems. Probably superior in theory and doesn't cause
> any issues as long as you're dealing with a single machine and
> unchanging hardware configuration... but then you have a drive failure,
> restore your backups onto new hardware, and you're hosed because the
> system wants to boot from a UUID that no longer exists. (Yes, you can
> recover from that situation - I know because I've had to do it - but it
> doesn't Just Work(TM) effortlessly.)
There are, of course, five different ways to do this (at a
minimum):
1. /dev/sda1 is based on discovery order. Changes in discovery order
may indicate a significant problem that you need to investigate -- or not.
2. /dev/disk/by-id/ata-Samsung_SSD_850_PRO_256GB_S251NXAH217600A is based
on drive type and serial number. This is great if you treat changing a
disk as a serious problem that requires human intervention, and terrible
if you want a replacement disk to be handled automatically.
3. /dev/disk/by-label/sheepdog is based on filesystem labels. These are
very good for mounting but useless for identifying specific disks,
and they can have collision problems.
4. /dev/disk/by-path/pci-0000:00:1f.2-ata-1-part1 is based on disk
controller topology. If you are interested in what's in a particular
disk slot rather than the particular disk in it, this is your choice.
5. /dev/disk/by-uuid/428366118125845852 identifies filesystems just
like by-label, and while it is unlikely to have an accidental collision
problem, does have a deliberate collision problem when you have copies
of filesystems.
6. Various advanced systems -- mdadm, LVM, btrfs, ZFS, hardware RAID --
have their own ideas about what to do and how to do it, which may include
any of the above methods as well as their own peculiarities.
That said, if you have a laptop or a desktop with 1-2 disks, you
are probably going to be perfectly happy with either /dev/sda1 or
LABEL=root-$HOSTNAME addressing.
Getting back to the original point, NIC names -- virtually every computer
has exactly one or two NICs, and is best served by eth0 and wlan0. The
computers with 3-5 NICs are usually best served that way. More complex
naming schemes are helpful when you have a router or switch, and it's
nice that Debian supports that, but hardly a good default.
-dsr-
Reply to: