Re: Why I don't like UUIDs (Re: can't mount sdf1 in stretch, gparted claims its fat32)
On Wed 05 Feb 2020 at 22:54:33 (-0500), Michael Stone wrote:
> On Wed, Feb 05, 2020 at 07:33:38PM -0600, David Wright wrote:
> > 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.
>
> You seem to just be stuck in this mindset where you think that it's
> somehow weird or unusual to name a root filesystem "root" instead of
> "kumquat" or some other meaningless string.
I opined that it's unwise to LABEL a filesystem "root" if you're using
LABELs as the determining name. It's not weird, and I have no idea
whether it's usual or not. The reason I called it unwise is that it's
limiting. For example, if I make it a habit to call the root
filesystem on this laptop "root", what should I LABEL the other root
filesystem as? Is it sensible to have two fstab files like:
LABEL=root / ext4 errors=remount-ro 0 1
LABEL=previous /media/previous ext4 errors=remount-ro 0 1
and
LABEL=previous / ext4 errors=remount-ro 0 1
LABEL=root /media/previous ext4 errors=remount-ro 0 1
That's what I mean about excessive overloading of meanings.
> I don't really have a
> response to that except to note that in my experience your naming
> conventions are an outlier and that it's a waste of time making
> assertions about what people should use as names instead of simply
> acknowledging what people actually use as names.
I have very little knowledge of what people are using as names, if
anything, unless they post them here. That doesn't prevent my having
an opinion, nor anybody else. How I spend my time is up to me.
I thought I had limited my assertions to pointing out that your
arguments appeared to be directed against things *not* stated,
like "labels prevent problems".
> > > 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.
>
> Again, asserting that using labels in a fashion that avoids potential
> collisions is "blindlingly obvious" implies that the problems I've
> seen people have with label-based schemes must mean that they're too
> ignorant to do the "obviously" correct thing. That seems presumptuous
> at least.
Pointing out a pitfall to someone doesn't mean that you're calling
them ignorant, particularly in a forum like this where you don't
have any idea who "they" are.
> OTOH, following best practices when copying raw partitions (including
> changing the UUID) seems to be something to be glossed over
> (presumably because only changing the label in that exact case is
> "obvious"?)
No, I'm not trying to gloss over it. What I would say is that if you
have a partition LABELled sex and you clone it, and then you
find yourself typing
# mount LABEL=sex /media/myclone
you're more likely to notice the duplication than if you were typing
# mount UUID=c12a7328-f81f-11d2-ba4b-00a0c93ec93b /media/myclone
(And I assume that nobody types these strings; they either cut and
paste them or devise a method of tab-completion.)
> > Stefan and I were posting why we like names. The uniqueness of UUIDs
> > is a given. (Ironically, it's in the name.)
>
> Perhaps (although the fact that they won't be unique if you copy the
> raw filesystem is a recurring theme) but the argument at the top of
> the thread seems to be that they somehow change unexpectedly and can't
> be relied upon--which would seem to be an even more serious problem
> (if it existed).
That's right. The only credence I give to that post is that any change
was unexpected for GH.
> > And it's a different
> > argument from the one you appeared to make,
>
> Yes, I argued against the proposition that actually started the
> thread, which seemed to be that UUIDs are somehow unreliable--in
> particular,
> as compared to labels.
Again, the only credence I give is that LABELs suit GH.
Nothing more.
> For some reason talking about why that isn't
> actually the case makes you start talking about straw men, as though
> you either didn't read or couldn't remember posts from a couple of
> days ago.
No, in the post where I brought up strawman, I had already given two
references to where GH made the original assertion that UUIDs
change at "unexpected" times.
> > which was that you dislike
> > using names because other people (presumably) misuse them.
>
> And you've explained that anybody who uses them other than in the
> (extremely idiosyncratic) manner you prescribe is just doing them
> wrong and its their own fault if there are problems because they must
> be dumb. I'm glad we've managed to so succinctly summarize each
> other's position.
There a difference between opining that somehing is unwise and
condemning it as wrong.
> If I were to summarize my own position it would simply be that I
> encourage people to be aware of potential issues that arise when
> labels collide¹, and that UUIDs are a (not unreliable²) alternative that
> may work better in some circumstances³.
I think I've made similar points: ¹ too much overloading of meaning
can lead to collisions (your "root" example), ² that SM didn't fairly
represent what GH posted, and ³ that UUIDs are invaluable when dealing
with commodities.
> > OK, perhaps
> > you run a helpdesk.
>
> The closest I come to that is this mailing list.
>
> > > 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.
>
> Nope...you need experience with more systems. :)
Well, I know about Windows, which appears to use LABELs that would
conflict were you to rely on them. I can also see overloading in
action: a partition LABELled "Windows8_OS" that's actually Windows 10.
But I'm not really interested in discussing Windows problems on
debian-user.
In any case, that comment was just an aside about the pre-UUID days
of the d-i, resonating with my next comment, about how we had to
survive without them.
> > > > > 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
>
> What is "that"?
Bringing up the sentence "labels prevent problems" and then giving
arguments to counter it, thereby suggesting that I has supported that
sentence in any way.
> You said "It seems that saying 'keep the vg names
> unique' is not very different from saying to keep filesystem LABELs
> unique." I agreed, then clarified what the issue is if they aren't
> unique. Then I explained why I think this is an important point to
> emphasize. I'm confused about what it is that you think that I think
> you suggested.
>
> > , you bring
> > it up, then knock it down: isn't that the definition of a strawman
> > argument?
>
> No. You seem to just like to say "strawman argument" regardless of
> whether it's applicable. Keep tilting at those straw windmills, I
> guess?
Cheers,
David.
Reply to: