On Sat, May 19, 2018 at 11:09:12PM -0700, Rick Moen wrote: > Quoting Craig Sanders ([email protected]): > > > Fortunately, you can assign labels to partitions or filesystems when you > > create them (or add one later), and these are much easier to read and use. > > Care to learn hour to make a Linux system go belly-up in a way field-proven > to puzzle Linux experts for days? Simple: Accidentidally connect two disks > with the same assigned disk label, and then attempt to boot it.
Yeah. This is why i use labels that include the hostname - like "ganesh_boot" or "ganesh_swap1" rather than just "boot" or "swap1". i.e. label collisions are not an accident, they're the inevitable result of poor planning. > This was posted a decade or so ago to the Silicon Valley Linux User Group by > one of the leading experts who'd just solved the problem after being stumped > by it for days. (I can't remember the exact signs of distress the system > gave, if any, before falling over.) > > I didn't try to replicate the problem. I merely made a mental note that, > IMO, this was an adequate reason to eschew disk labels completely: one fewer > bizarre failure mode to watch out for. The trouble is that unless you want to use UUIDs there isn't any alternative. UUIDs are ugly, but they work. They consistently and uniquely identify the drive, partition, filesystem as required. Labels aren't ugly but they're subject to human error, fallibility, and laziness - it's easy to think that "root" is a great label for the root fs if it doesn't occur to you at the time that you might one day want to put that drive into another system (that may also have such intuitively obvious filesystem labelling) > I always imagined that someone was handed an account of that shambles and > told 'Please design for the Linux community a disc identifier system that > avoids all such failure modes through the expedient of using an absolutely > guaranteed, totally unique identifier. Feel free to sacrifice all other > objectives such as ergonomics and human-compatibility. Just be absolutely > certain the identifiers are unique, at any cost.' Eh volia! UUIDs. There's not much use to a "unique" identifier that is only "unique" some of the time, or only unique as long as any humans involved don't do the kinds of things that us humans are prone to doing. UUIDs at least give almost-certainly-unique identifiers. The chance of a collision is somewhere between zero and almost-imperceptibly more than fuck-all (although the quality of the RNG can affect this). https://en.wikipedia.org/wiki/Universally_unique_identifier#Collisions So it makes sense to give a UUID to disks/partitions/filesystems by default. And allow the human operators to assign hopefully-mostly-unique labels to make things easier for themselves if they need or want to know or care about device names. The human operators should preferably apply a modicum of caution and planning ahead in their naming choices. BTW, UUIDs weren't invented by/for Linux. Linux just used the existing Ń–dea because it works. i.e. it does what it says on the tin. > > changes in the order that kernel modules are loaded > > FWIW, I generally compile my own kernel, and critical drivers get compiled > inline. Never seen the above problem, and my kernel practices may help > somewhat. and then one day you'll compile the latest shiniest new kernel and discover that the kernel devs really weren't joking when they said you can't rely on the names to remain the same. > > minor variations in the timing of exactly when drives are detected by the > > BIOS or kernel (e.g. sometimes a disk might take a few milliseconds longer > > to spin up on a cold boot) > > Still have never seen that on my systems. Still waiting, since 1992. It > may help that I favour relatively simple and homogeneous hardware. I see it frequently. But my main file server has 8 SATA drives plugged into an LSI SAS controller and a few more in SATA ports on the motherboard. drive spin up time varies enormously. My mythtv box is similarly equipped, but on a smaller scale. > > BTW, modern linux systems populate a directory called /dev/disk/by-id/ > > with symlinks to the actual device names. > > I look forward eventually to losing udev on server systems and migrating to > mdev, which among other things will lose the above. ;-> I find it useful. and far more informative than unreadable crap like /dev/c0t0d0p1 which is not much better than a UUID. and it works well with ZFS (which IMO is the only fs that really matters these days :) /dev/disk/by-label is also useful. udev does kind of suck, but that doesn't mean that everything it does sucks or that there aren't some good ideas in the sucky implementation. mdev already has helper scripts that create the same kind of /dev/disk/by-* symlinks that udev does. e.g. see https://github.com/slashbeast/mdev-like-a-boss/blob/master/helpers/storage-device craig -- craig sanders <[email protected]> _______________________________________________ luv-main mailing list [email protected] https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
