On Sun, May 20, 2018 at 12:09:22AM -0700, Rick Moen wrote:
> Quoting Craig Sanders ([email protected]):
> > The trouble is that unless you want to use UUIDs there isn't any
> > alternative.
>
> Well, speak for yourself.
>
> I've been using /dev/sdX (never used IDE ;-> ) on Linux since 1992, and for
> whatever reason never encounter the variety of ills you cite.

I haven't cited a "variety of ills" because there aren't a variety of them.
There's just one: assuming that drive device names will remain the same on
every reboot, every time, forever.  That one ill can result in a multitude of
problems, but they all stem from that one error.  And they're all avoidable by
simply not making that mistake.

> > 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.
>
> Personally, I'd settle (or consider settling, depending on outcomes) for a
> human-compatible identifier that's roughly as unique as an SHA1 hash

A SHA1 or MD5 or whatever hash is slightly shorter but no more human-readable
than current UUIDs.

Once you get beyond about 7 or 10 letters/digits in a code, human recognition
slows down to the rate at which each individual letter/digit can be recognised
and compared to each corresponding letter/digit in other hashes.

Humans just aren't very good at memorising and compared long random strings of
letters and digits.

But that's OK.  UUIDs are for computers.  Labels can be applied and used by
humans. Humans sometimes need labels even to differentiate between only two
very similar-looking items, like tea and coffee jars.

> > So it makes sense to give a UUID to disks/partitions/filesystems by
> > default.
>
> You keep telling yourself that. ;->

I don't need to tell myself the bleeding obvious.

There's a demonstrable need for things like drives and partitions and
filesystems to have unique identifiers.  Labels don't do the job adequately
because they're made up by humans.  Any guaranteed-unique identifier is going
to be ugly and unpleasant to use - that's essentially unavoidable.

Unavoidable unless you want to do something like have 10 or 20 random words
with at least 5 letters each in each unique identifier.  I do stuff like that
for passwords but it would suck for partition or filesystem identifiers.
Abusing my randow pw generator to demonstrate the point, that would result in
ghastly crap like:

mount -t ext4 -o rw LABEL="71 hypergamous Lasagnes 8 uttermost onychophorans 57 
Warrendale 16 bandages 39 riping 81 anthropometric miscegenations truisms" /home

Almost certainly unique and occasionally generating some amusing word
juxtapositions, but this is actually worse than a UUID.  UUIDs are much
shorter.

> > 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.
>
> You keep saying that.  It's been 26 years.

Good for you. You're lucky. However, assuming that your experience is
universal is always a bad idea. Giving out advice based on that presumed
universality is even worse.

Saying "It won't happen, I've never seen it" isn't anywhere near as useful
as saying "It **CAN** happen" and then taking the trivially minimal steps to
ensure that it **won't be a problem if it ever does**.

This comes under the heading of "Sensible precautions to take just in case..."

In fact, these days, using UUIDs in /etc/fstab is the default for new installs
- no steps needed at all.  You have to override the defaults to force a system
use the unreliable /dev/sdX device names. and if you're going to go to that
minor trouble, put in a tiny bїt more effort and use labels.

> > 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.
>
> Yeah, personally I'd carefully avoid that.

You mean by NOT having lots of drives in my machines?

Sure, I could do that.  Then they wouldn't be fit for the purposes I built
them for.

even in the distant future when multi-petabyte drives are available, I'll
**still** have at least two drives in every machine I build (because I don't
trust non-mirroed storage. at all.)

and whenever you have more than one drive in a system, you can't rely on the
drive device names to remain the same across reboots.  They might actually
stay the same for a long time - even years - but they're not guaranteed to do
so and it is foolish to configure anything to depend on that.

craig

--
craig sanders <[email protected]>
_______________________________________________
luv-main mailing list
[email protected]
https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main

Reply via email to