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.