UUIDs on drives

[Derek Broughton]

Brian Astill wrote:

> On Thursday 14 August 2008 13:48:44 you wrote:

Please teach your mail program to quote properly.  "You" isn't an
attribution, and you're replying to more than one of us, anyway.

>> > If there is a key to unravel the info implicit in /dev/hdb3
>> > (Primary partition on the Slave drive) from its UUID, would
>> > someone please publish it.
>>
>> huh?
> The "old" system tells what drive and what partition it refers to.
> UUID doesn't.  If it did, I would complain MUCH less.

You're not paying attention.  UUID has nothing to do with that.  It's just 
a way to look up a _filesystem_.  Not a device, and not a partition.  If
you want to see what's mounted, you use "mount", as always.

>> create a file system, they all get a fresh new UUID.

> But what if I don't want to?  Say I have a 32-bit version of
> Ubuntu with a separate /home partition.  Assume that after that I
> want to try the 64-bit version on a separate partition without
> risking damage to my /home. so I just install all on the one
> partition.  If the install goes well, I need to change fstab so
> it mounts my home directory, rather than the one it set up by
> default.  How, if UUID is all I have to identify it?

By UUID.  Or by device (but you want to be certain it's fixed).  Or by
label.  It's all your choice.  But really, you're making a mountain out of
a molehill here.  In this case you copy the line for that partition from
your old fstab to your new one.  Pretty simple - and again, it's irrelevant
whether the partition was originally mounted using UUID or device name or
label.

>> you can
>> change/create a new UUID with the filesystem utilities if you
>> want. (like tune2fs, I believe, for ext3)

> But it already has one, which is used  (in the example above) by
> an existing system.

Yes, it does.  That _is_ the point of UUID - it being fixed, and relatively
unique, for a particular filesystem.  He only gave you that information
because it appeared you wanted to be able to write your own UUID.

>> More bits = less chance accidentally duplicating a UUID from
>> random creation.
> 
> That is _the_ issue, SFAIAC.   I would not object to a rational ID
> plus a random component, so there would be no duplication.

When you find some duplication, _then_ object.  I don't believe you're ever
going to find any, even with a 4-byte vfat UUID.   2**128 is still a very
big number.
> 
>> I deal
>> with system that have several hard drives on multiple
>> controllers.. I assure you, this change is not only progress,,
>> it's outright necessity.
> 
> Your server world is different from my desktop world.  In my world
> the trend is to fewer, but much larger, drives.  In my world we
> often have a "working" drive, and use the other
> for "experimenting" - changing partitions and usage as desire
> dictates.  For us, UUID seems to present an unnessary barrier.

Only because you make it so.  Besides which, UUID has to do with
_filesystems_ not drives.
-- 
derek