Re: multiple volumes with same name

Ross Boylan <[email protected]> wrote on 05/04/2007 11:06:42 AM:

> I moved some disks from a system that failed to a different one that
> was already setup.  As a result, several different disks have the same
> logical volume.
>
> First question: what happens in this case?  It looks as if the "first"
> one it hits gets mounted, and the other is left unmounted.

That is correct.  Whichever one EVMS discovers first will get the volume
name.  When EVMS tries to create the second volume with the same name it
will get an error because the name is already taken.  The same is true of
regions and containers.

To get technical, EVMS will create the one volume and leave the other one
uncreated.  I think you meant that rather than "the 'first' one it hits
gets mounted, and the other is left unmounted".  EVMS does not
automatically mount file systems when it discovers them.  (As a courtesy to
help you avoid having to switch focus to a command prompt EVMS will let you
mount an unmount filesystems through its user interfaces, but it doesn't do
it automatically.)

If you are truly referring to mounts, then I suspect it is the automounter
mounting the EVMS volume.  Only one of the two volumes can be mounted since
EVMS will only create one of the two volumes.

> Second question: I took one of those unmounted volumes and mounted it
> under a different name.  Is that OK?  Have I done anything strange
> like creating a volume on top of a volume?  The underlying storage
> object is an evms LVM region.

I you create the volume with a different name and mount it elsewhere you
should be OK.

> A few more ancillary questions:
>
> After I created the new volume name for the region I realized I didn't
> want it as a volume at all.  I went to delete it with evmsgui, but it
> gave me messages that it was going to erase the underlying
> filesystem--even when I did not ask it to go recursively.  Is there a
> way to undo just the creation of the volume?

EVMS does not allow you to delete a volume without removing the file
system.  It is designed that way.  There were debates as to whether one
should be allowed to leave a file system on an underlying object.  In the
end we decided that it was not safe to leave the filesystem lying around.
For example, the volume may have spanned several objects.  If the
filesystem was left on the objects when the volume was deleted, each object
would have a piece of the filesystem.  The objects could then be combined
in a different way to form a new volume.  Depending on how the new volume
was constructed, it could appear that it had a complete file system on it,
when it fact it has only pieces.  You could be able to mount the volume,
but the filesystem would eventually trip over (kernel panic?) the parts of
the volume that aren't really filesystem data.

> Finally, if I had storage objects that spanned disks (a situation I've
> deliberately avoided), would evms have been able to reconstruct them
> properly, even with the disks at new hardware locations (i.e., the x
> in hdx has changed)?

In most (all?) cases, yes.  Volume constructs such as LVM and MD write
their metadata in such a way that they can reconstruct their regions
without having to know the name, major:minor, etc. of the objects that the
region comprises.  They just scan all available devices looking for their
metadata.  The metadata describe which devices belong to a region and how
to build the region from the devices found.

Steve D.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

_______________________________________________
Evms-devel mailing list
[email protected]
To subscribe/unsubscribe, please visit:
https://lists.sourceforge.net/lists/listinfo/evms-devel