Re: Question to new network device names
On Thu 24 Aug 2017 at 10:20:52 (-0400), Dan Ritter wrote:
> On Thu, Aug 24, 2017 at 08:30:33AM -0500, Dave Sherohman wrote:
> > 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.
I'm having difficulty imagining a scenario where the identity
of sdaX, in particular, is unimportant (for most people).
> 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.
I find this useful for identifying bootable Debian USB sticks
whose 'soft' identities vary from one revision/architecture/whatever
to the next. It probably fails for multiple cheap generic USBs
that have no firmware serial number.
> 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.
I find this ideal for most disks. It's amazingly easy to write the
human-friendly LABEL on the device with a marker pen, and I do use
stable partitioning numbering. All my hard drives are labelled thus,
and the USB sticks and SD cards that aren't already identifiable.
But I understand that I'm working within my own defined universe
of devices, and don't expect this to work for all others.
(Now think NICs.)
> 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.
If genuine GUIDs, they're great for machines but no so much for
humans. If they're not genuine, they have to be checked, if it
matters, and that can be tedious.
But in connection with the original NIC discussion, the absence
of disk/by-uuid would be sorely missed if it weren't there, which
is why some improvement on eth0, eth1 assignment was needed,
and the result was a very flexible system IMO.
> 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.
With two disks on a BIOS computer, you have an immediate problem,
don't you? That what disk-swapping was all about. And that was when
everything was on ATA.
But now look at the debates here on, for example, how an SD card
is going to appear to the system. The schematic diagram of any laptop
looks like a forest of USBs (and other types) so which is going to win
the race to become sda?
> 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.
There are plenty of ways that you, or Debian, can set a default.
But it surprises me that so many people grumble about this change.
The history of computing is littered with statements like
"virtually every computer has exactly one or two NICs".
This list is full of postings about the complex DNS system. But
how long did /etc/hosts last? Some complexity is unavoidable,
but if you try to avoid it, you pay for it later. Look at timezones.
Ever allowing computers' internal clocks to run on local time
was, with hindsight, a big mistake. Leap seconds might also
be seen the same way (still under debate).
Cheers,
David.
Reply to: