The problem with this in a z/VM world is that many disks are not complete DASD's, so this value is not unique; possibly not even unique within a single Linux image. This scheme trips us up in two ways:
The first is that, while all our DASD are 3390 mod 27 devices, we tend to build out Linux images using two mod 9 virtual devices. In roughly half the builds, these two minidisks are on the same physical device, and can cause a conflict because the UID is not unique. The second is that we clone Linux images by copying the minidisks to new extents, which are likely not on the same physical device as the original. At that point, the mounts fail because the UID cannot be located. At least for the z/VM environment, the /dev/disk/by-path is a better choice for building mounts in fstab. The virtual CUU of the minidisk will definitely be unique within a single virtual machine, and, unless you savor insanity, cloning images will keep the minidisks at the same virtual CUU as the master image used. The choice to use UID in the physical Intel world may be good... But for a virtual world, zSeries or Intel, it would seem, to me, to be a very poor choice as a default. -- Robert P. Nix Mayo Foundation .~. RO-OE-5-55 200 First Street SW /V\ 507-284-0844 Rochester, MN 55905 /( )\ ----- ^^-^^ "In theory, theory and practice are the same, but in practice, theory and practice are different." On 6/10/08 4:37 PM, "Alan Altmark" <[EMAIL PROTECTED]> wrote: > > The UID is indeed unique to the device. It consists of manufacturer's > name, plant of manufacture, and a serial number. That allows you to > identify a volume, independent of how you access it (UAs, device numbers, > chpids, etc.). ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
