On Thu 24 Aug 2017 at 12:30:37 (-0400), Dan Ritter wrote:
> On Thu, Aug 24, 2017 at 10:43:56AM -0500, David Wright wrote:
> > On Thu 24 Aug 2017 at 10:20:52 (-0400), Dan Ritter wrote:
> > > 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).
↑↑↑↑↑↑↑↑↑↑↑
> Say you boot from /dev/nvme0n1p1 (a high speed NVMe SSD) and
> have /dev/sda, b, c and d in an mdadm RAID10.
>
> mdadm will scan all disks looking for its signature, and will
> assemble them into /dev/md/0 regardless of physical disk
> location. So it really won't matter to you whether you have the
> same disks in /dev/sdX from boot to boot as long as they are
> all there.
>
> But for most people, most of the time, swapping /dev/sda and
> /dev/sdc would be a problem.
Yes, I assumed that *most* people boot from sda.
> > 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.
>
> On a well-working computer, device discovery order is constant without
> physical changes. sda will always be sda, until it breaks or
> something else (bad) happens.
Passing comment: our memories are short. I remember the time when the
sole disk in a machine would vacillate between hda and sda if one was
running (as I always do) two consecutive versions of Debian. A
different cause, however.
I haven't looked back to see the number of screams. I'd left
debian-user by then on the grounds of traffic volume.
> > 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?
>
> They don't. The SATA, SATA-DOM or NVMe disk selected by the UEFI or BIOS
> will become sda. Or if you've got an internal USB port with a
> stick in it, that might be a selected candidate. In no case
> should it change without hardware failure or physical
> rearrangement.
>
> The question is, how will your newly plugged in SD card become
> sdk rather than sdj, and the answer is that mass storage devices
> that are expected to be rearranged should be treated differently
> from those which are expected to always be available from
> boot-time onwards.
You just made an assumption that does not match my reality, and
you didn't even realize that you made it. :) The SD card may
already be plugged in and contain the OS itself.
But seriously, the only point I'm trying to make here is that even the
single disk computer user should not rely on /dev/sdX names. When they
buy a new disk with perhaps a new technology, or have a failing drive
and want to copy at device-level (ie dd-style), that's precisely not
the time to be distracted by coping with hardware races and shifting
device names.
> > > 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.
>
> People grumble about changes for several nonexclusive reasons:
>
> 1. The change broke what they were doing.
> 2. The change broke their mental model of what they were doing.
> 3. The change did not bring them perceived benefits.
> 4. The change appears arbitrary.
> 5. The change fixed a problem but they perceive better ways to
> solve the problem.
> 6. The change creates new problems.
Summarising, people will grumble.
> > The history of computing is littered with statements like
> > "virtually every computer has exactly one or two NICs".
>
> It used to be zero.
>
> We are currently in the phase of history where this statement is
> true. NICs are both ubiquitous and cheap, yet devices tend to
> come with one (only an ethernet port or only a wifi radio) or
> two (one of each of those, or a wifi radio and a cell radio).
>
> Devices can add more, but they are always special cases: my
> Debian-running firewall has 5 ethernet ports. I occasionally
> add a USB ethernet frob in order to isolate a device that I want
> to talk to directly. Special cases deserve special treatment.
>
> I expect the statement to remain true for the next ten years.
>
> Do you expect differently? If so, why?
I didn't expect to have to deal with this problem when I ran a PC
with two identical NICs; it's highly unusual for me to be ahead of
the curve. But I know that the future will always confound our
expectations. So why not build in flexibility. The tools are
there on the web page for hiding any complexity.
> > 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).
>
> /etc/hosts still acts the way it always did -- put in an entry,
> it overrides DNS.
>
> Timezones are a human legal-social problem, and the ability of
> technology to deal with those is known to be problematic.
I see it differently. Technologists didn't plan for a time when
electronic devices would know the time, care about it, and be
capable of movement around the globe. What surprises me is that
many/most of those technologists live in a country with four
timezones and a multiplicity of civil times, so you might have
expected them to deal with the problem from the start.
Cheers,
David.
