[aklug] Re: UUIDs

On Mon, 6 Apr 2009, Shane R. Spencer wrote:

> Agreed, UUID are essential to building scalable operating systems since
> it helps define devices based on a signature that is, for the most part,
> unique to the system that generated it if it's careful and UUID ends up
> being used for physical volumes/raid volumes, raid devices themselves,
> filesystems on top of those devices and of course swap devices and hey..
> how about files themselves for some filesystems! UUID simply being a
> universally (anything) unique identifier. So assigning a raid volumes
> UUID to a mount in /etc/fstab and so forth won't do a lick of good.
> Sorry if this was the case.
>
> /etc/blktab (generated by blkid) and the blkid utility are great for
> peeking at block devices to see the UUID of the filesystem they may be
> carrying.
>
> Also, in a previous post on duplicating a drive, make sure you don't
> clone filesystems you expect to mount later if both block devices will
> stay in your system. Two or more identical filesystem UUID equates to
> failure. The tools that generate and tune filesystems can usually
> change the filesystems UUID if this is the case.
>
> For hardened devices I often issue an LVM snapshot of the root
> filesystem and mount the snapshot vs the root filesystem by default on
> boot. I write back changes whenever I need to as it helps me maintain a
> very clean and stable environment for telco related stuffs to operate
> in. In this situation I can't afford to use UUID based mounting since
> making a snapshot itself means multiple block devices point to the same
> filesystem, essentially, and will return the same UUID when queried.

Good stuff, here, Shane! If you're running LVM you don't need UUID, anyway,
since the LVM layer provides a stable naming convention regardless of what
the backend PVs are.

:-) LVMs are good stuff, and I wouldn't want to manage storage without it.

         --Arthur Corliss
           Live Free or Die
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Mon Apr 6 10:01:29 2009