Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)
On Wed 05 Feb 2020 at 15:59:27 (-0500), Michael Stone wrote:
> On Wed, Feb 05, 2020 at 01:43:37PM -0600, David Wright wrote:
> > On Wed 05 Feb 2020 at 09:00:41 (-0500), Michael Stone wrote:
> > > On Tue, Feb 04, 2020 at 07:04:16PM -0500, Stefan Monnier wrote:
> > > > While I'm sure this can be managed by explicitly setting UUIDs, I've
> > > > found it much more pleasant to manage explicit names (I personally
> > > > prefer LVM names over filesystem labels, but filesystem labels work well
> > > > for those filesystems I don't put under LVM). Not only I can pronounce
> > > > them and they carry meaning, but they tend to be much more visible (and
> > > > hence easier to manipulate).
> > >
> > > I dislike using names becaues it's *much* more common to find name
> > > collisions than UUID collisions. (E.g., a bunch of disks with
> > > filesystems all labeled with easy to remember names like "root" or
> > > "home".) Reboot with a couple of those in your system on a
> > > label-oriented configuration and you may have a very bad day.
> >
> > Rather a strawman argument there. There's no reason not to choose
> > sensible LABELs, unlike the examples you've given there, which fail
> > for at least two reasons: they're unlikely to be unique and they're
> > too overloaded with meaning.
>
> What does "sensible" mean in this context? On a static system all of
> this is a complete waste of time because nothing changes. If you start
> upgrading disks, using external drives, moving things around, etc., it
> may very well be that the same "sensible" label applies to a
> filesystem found on more than one disk.
To make that argument, you have to put scare quotes round sensible
because common sense would lead you to use different LABELs for
partitions that you intend to distinguish by LABEL. To do otherwise
would be like suggesting that two teams who play in red should do
so without a change of shirt for one team.
> Can problems be avoided
> through careful attention to detail?
I'd call the LABEL problem's solution blindingly obvious. Ironically,
one has to be more careful with *certain* operations when using UUIDs
because one is less likely to spot a duplication. I'm thinking of,
say, copying partitions.
> Sure--but the same is true of
> many other systems. I submit that labels are not inherently "better",
> but merely a matter of preference.
I haven't said one is better than the other, but have just pointed out
why I like LABELs, which you said you dislike.
> If you like them, great! Have fun!
> If giving every thumbdrive its own label and mountpoint makes you
> happy, go for it. I generally expect thumbdrives to be consumables,
> mount them at generic points, and call it a day. YMMV.
And I supported you there, but you snipped it; I wrote of UUIDs:
"it's obviously a sensible scheme to use where there are
large numbers of commoditised objects to name."
> And FWIW, those aren't "strawman arguments", those are based on things
> I've found in the real world.
Stefan and I were posting why we like names. The uniqueness of UUIDs
is a given. (Ironically, it's in the name.) And it's a different
argument from the one you appeared to make, which was that you dislike
using names because other people (presumably) misuse them. OK, perhaps
you run a helpdesk.
> Just because you personally use a
> feature in a particular way doesn't mean everyone else does. Sometimes
> a standard install of an OS can default to labeling schemes that cause
> conflicts if you put the drive from one machine into another
> machine--so this really isn't something I'm making up out of thin air
> that never happens in real life.
IIRC you're describing Debian in the early days, when partitions were
configured only by their kernel names, rather like some people prefer
their network interfaces to be named.
> > > LVM is
> > > more resistant to that as long as you keep the vg names unique. (Call
> > > everything vg0 and you're back to having a bad day.)
> >
> > It seems that saying "keep the vg names unique" is not very different
> > from saying to keep filesystem LABELs unique.
>
> It's pretty much exactly the same. If you have multiple logical
> entities addressed by the same name, you might not get the entity you
> expected to get. This isn't always obvious to someone starting out who
> reads something like "labels prevent problems" and hasn't yet run into
> cases where that isn't true and thus hasn't adopted strategies to
> avoid those problems.
That's another strawman argument: I haven't suggested that, you bring
it up, then knock it down: isn't that the definition of a strawman
argument?
LABELs are a tool, as are UUIDs. I like both. UUIDs are great for
creating a nonce name; so good, we wonder how we got by without them.
But LABELs have some advantages (like brevity, memorability, meaning)
which persuades some people to use them without abusing them.
Where I might part company with Stefan is in adopting names with too
much meaning, unless they're aliases. So I wouldn't call my server
"server", or a disk "main" (unless, say, my others were named
briny, ocean, and sea). There's an RFC (1178) that gives advice on
the subject (in the context of hostnames).
Cheers,
David.
Reply to: