[conspire] UUIDs, LVM, etc.

[Michael Paoli]

> Date: Sun, 28 Mar 2010 15:45:34 -0700
> From: Rick Moen <rick at linuxmafia.com>
> Subject: Re: [conspire] verifying I'm doing this correctly - fdisk,  
> mkfs.ext3, e2label for FreeAgent Go 1T
> To: conspire at linuxmafia.com

> /sbin/fdisk, for that matter).  Which brings up the matter of disk
> labels, and also of the more-recent, more-fashionable solution to the
> same problem, UUIDs.  <sigh>

My preference is generally:
o use LVM where feasible and not contra-indicated (for me and the
   environments I deal with, that's typically a lot, but not everywhere).
o for most everything else, use UUID - but do also track and note device
   and LABEL

Rationale:
o LVM has many advantages.  It also uses its own flavor of UUID
   on PVs for LVM to be able to identify them, and to determine to which
   (if any) VG they belong.  LVM thus rather automatically handles
   finding the stuff on disk and setting up the correct, nice, consistent
   device names for accessing one's LVM LVs (Logical Volume devices).
o UUIDs are quite unique, and thus (with proper handling) UUID conflicts
   are exceedingly improbable.  Unfortunately their user-friendliness
   could almost be described as user-hostile.  Fortunately, however, e.g.
   /etc/fstab allows for comments - that can greatly compensate.

Examples:
These are some lines from an /etc/fstab file (with whitespace in lines
squashed to a single space) ... note that the lines may be quite long
(:se leftright is very handy in BSD vi / nvi, but not vim).

$ perl -n -e 'next if /^[ \t]*#/; s/[ \t]+/ /go; print if /UUID=/o ||  
m|/vg|o' /etc/fstab
UUID=d1156f8a-7fb5-4aa1-8ce1-d348581e3e33 / ext3 errors=remount-ro 0 1  
#/dev/sda5
UUID=68cbbf74-3b2b-4722-9dbd-10b113f7d026 /boot ext3  
ro,nosuid,nodev,noatime 0 2 #/dev/sda1
/dev/vg00/home /home reiserfs nosuid,nodev 0 2
/dev/vg00/usr /usr reiserfs ro,nodev,noatime 0 2
/dev/vg00/var /var reiserfs nosuid,nodev 0 2
/dev/vg00/swap none swap sw 0 0 #LABEL=swap,  
UUID=6a129e5b-5c2d-4eb8-99f3-a919001ea041
/dev/vg01/backup /var/local/tower reiserfs rw,nosuid,nodev 0 3
$

In the examples above, I may not have every bit of UUID and LABEL
tracked, but where I mount by UUID or LABEL (I generally recommend not
mounting by LABEL - probability of conflict is rather high - e.g. in
recovery or other scenario where other media is being introduced), I
also at least note (in comments) the device.  For the LVM stuff, I
haven't bothered to note LABEL or UUID in general - but don't
particularly need to - as long as LVM is working, the LV device names
should be available and useable, and should LVM ever not be working,
then, UUIDs and LABELs wouldn't particularly help to access those LV
devices anyway.  So yes, the LABEL and UUID shown on /dev/vg00/swap are
rather superfluous (probably left over from when I was mucking about
testing various ways to have swap identified in /etc/fstab).

UUID collisions?  Highly improbable with proper handling.  When
replicating filesystems, be sure to use proper care to NOT duplicate the
UUID (or at least immediately change it to be unique as soon as
feasible).  The same also applies to LVM PVs.  Note that in some rare
circumstances one may want to "duplicate" a UUID - that's usually only
a good idea if the original UUID no longer exists on the device from
which it came or as the same UUID on of any device (e.g that disk was
destroyed, but we want to match it to our (restored) /etc/fstab, rather
than change the UUID in /etc/fstab and if needed, on the restored to
device).  In most cases however, it's still a better idea to create a
new UUID, than replicate one that was used before.

Also of note:
Reasonable persons/perspectives will reasonably differ, e.g. LVM has
its downsides (e.g. complexity & learning curve) - but also many
additional advantages (management, flexibility, ...).
Some of the newer device management stuff may be rather to quite handy -
i.e. specifically configure file bits just right under /etc, and one
should typically be able to get the same hardware device and partition
to always show up as the same /dev device ... at least I think that
should more-or-less be the case (I haven't particularly tested out that
theory yet).