Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)
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:
> > > > Me too, so I usually label the permanent stuff at least. UUID's can and
> > > > will change for no detectable reason.
> > > For those reading along or finding this in search results: no, filesystem
> > > UUIDs don't change for no detectable reason. Don't implement anything based
> > > on this theory.
> >
> > What he meant is that filesystem UUIDs are (re)created automatically
> > based on a heuristic of what it means for a filesystem to be "the same".
>
> You understand that he didn't actually say that, right? This seems
> like your own personal bugaboo instead.
Yes, what he wrote is elaborated in postings like
https://lists.debian.org/debian-user/2018/01/msg00787.html
https://lists.debian.org/debian-user/2018/01/msg00791.html
> > 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.
I don't suppose either of us will meet a UUID collision in our
lifetimes, and it's obviously a sensible scheme to use where there
are large numbers of commoditised objects to name. Look at cars.
For practical purposes, a VIN is a (U)UID: great for computers,
but totally impractical for human use, hence licence plates,
whose numbers are chosen to be unique only within a juridiction.
My jurisdiction is Home, so every host gets a short memorable
name, and each disk, stick and card does too. Their filesystem
LABELs relate to those names. All are marked with those names,
and I couldn't manage that with UUIDs. None of the names carry
any functional meaning, because functions necessarily change.
Other people will choose LABELs in different ways, but the fact
that some people will choose unwisely does not condemn the method.
> 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.
> On Tue, Feb 04, 2020 at 10:19:25PM -0500, Stefan Monnier wrote:
> > > > PS: The only problem with LVM names is that Linux doesn't let you
> > > > rename a volume group while it's active (at least last time I tried),
> > > > which makes it painful to rename the volume group in which lives your
> > > > root partition.
> > > How painful is it to dd a live cd, boot from it and rename?
> >
> > Very. It's called "downtime".
> > Every time you have to reboot, it means your OS has somewhat failed you.
>
> I'm trying to think of a reason to rename the root partition that
> doesn't involve downtime and coming up empty.
I don't know what the implications of LVM are because I've not used
them. Consequently I don't know why Stefan wrote 'The root partition
is always called "root"', or whether "called" even refers here to a
filesystem LABEL or something else. Some of the posts seem to conflate
the terms partition, VG, LV and LVM.
Cheers,
David.
Reply to: