Posted by: Anonymous
[ip: 82.182.32.28]
on September 14, 2008 09:26 PM
I think this article fell short on describing how and why this is a feature for today's systems, I personally believe it fixes an ancient problem in the Linux management.
I believe this feature is best descibed for SCSI subsystems and such. If you have SAN or SCSI attached disks and have to rescan the chain, the disks can change place so sdb is moved to another id. And that can be a bit of a problem.
A case study.
I built a XEN Enterprise pool using SAN as shared storage. XEN uses LVM volumes for managing virtual host storage and to make sure a attached storage LUN did not get reconfigured it was presented to XEN using UUID.
In case you have 3 disks (sda, sdb, sdc) mounted as /dev/sda1 /mnt/disk1, /dev/sdb1 /mnt/disk2, /dev/sdc1 /mnt/disk3 and detach sdb and make a scsi rescan. Your disks will be shown as /dev/sda and /dev/sdb. This means that the disk you previously had mounted as /mnt/disk3 now is mounted as/mnt/disk2 and if unlucky you can trash what you are running on that system.
An even worse case would be if you have a whole bunch of disks in an storage (for backup or whatever) and the disks gets reorganized because of a rescan.
By mounting the disks by its UUID you make sure the right disk still is mounted on the expected place, even after a system re-configure.
In the XEN case it makes it possible for XEN to _not_ loose all of its configuration as you increase/decrease your storage.
And if unsure, you can look at to which device the UUID is soft linked by issuing:
$ cd /dev/disk/by-uuid/
$ ls -l
lrwxrwxrwx 1 root root 10 2008-09-14 20:24 68f57034-51ae-11dd-882c-63be9b0f4c9d -> ../../sda8
$ grep "68f57034-51ae-11dd-882c-63be9b0f4c9d" /etc/fstab
UUID=68f57034-51ae-11dd-882c-63be9b0f4c9d /home ext3 noatime 1 2
Or you can label the disks yourself and find them in:
$ ls -l /dev/disk/by-label/
Learn about Linux
Download Linux
Get Linux help
Well guess is can....
Posted by: Anonymous [ip: 82.182.32.28] on September 14, 2008 09:26 PMI believe this feature is best descibed for SCSI subsystems and such. If you have SAN or SCSI attached disks and have to rescan the chain, the disks can change place so sdb is moved to another id. And that can be a bit of a problem.
A case study.
I built a XEN Enterprise pool using SAN as shared storage. XEN uses LVM volumes for managing virtual host storage and to make sure a attached storage LUN did not get reconfigured it was presented to XEN using UUID.
In case you have 3 disks (sda, sdb, sdc) mounted as /dev/sda1 /mnt/disk1, /dev/sdb1 /mnt/disk2, /dev/sdc1 /mnt/disk3 and detach sdb and make a scsi rescan. Your disks will be shown as /dev/sda and /dev/sdb. This means that the disk you previously had mounted as /mnt/disk3 now is mounted as/mnt/disk2 and if unlucky you can trash what you are running on that system.
An even worse case would be if you have a whole bunch of disks in an storage (for backup or whatever) and the disks gets reorganized because of a rescan.
By mounting the disks by its UUID you make sure the right disk still is mounted on the expected place, even after a system re-configure.
In the XEN case it makes it possible for XEN to _not_ loose all of its configuration as you increase/decrease your storage.
And if unsure, you can look at to which device the UUID is soft linked by issuing:
$ cd /dev/disk/by-uuid/
$ ls -l
lrwxrwxrwx 1 root root 10 2008-09-14 20:24 68f57034-51ae-11dd-882c-63be9b0f4c9d -> ../../sda8
$ grep "68f57034-51ae-11dd-882c-63be9b0f4c9d" /etc/fstab
UUID=68f57034-51ae-11dd-882c-63be9b0f4c9d /home ext3 noatime 1 2
Or you can label the disks yourself and find them in:
$ ls -l /dev/disk/by-label/
#