Summary: recovering a diskgroup for an lsm setup

From: MacDonell, Dennis <DennisMacDonell_at_auslig.gov.au>
Date: Fri, 27 Apr 2001 15:14:35 +1000

Hi,

I got a few answers, but as it turned out the following worked for me
I virtually just repeated the original steps of creating and adding disks to
the disk group datadg.
(a) for the first disk in the datadg disk group I entered
voldg init datadg dsk2
(b) then for all the other disks (dsk3-dsk8) I entered
voldg -g datadg adddisk $DISK=$DISK
and that created the datadg in tack. The directory /etc/fdmns still held all
the details with respect to the advfs setup on the volume, so I was then
able to mount the disk and see all the original data.

Amazing!!!!!!!!!

Since LSM is a bit of a mystery to me, and I guess to a few other people, I
have included the responses -
(a) from O'Brien, Pat [pobrien_at_mitidata.com]

you should start with voldisk list, voldg list, and maybe voldg list datadg,
voldctl list. I expect voldisk list to show the disks within the datadg
group

(b) from Warren Sturm [wrsturm_at_mtroyal.ab.ca]

since you have the rootdg group already, you can try to recreate the
volumeset into a different
disk group. Diskgroups other than rootdg are supposed to be portable
between systems.

voldisk list
        to see what drives are available. Those tagged as offline can be
put
online with the command
voldisk online xxxx

        From here you may want to check the man pages for voldisk and voldg
for
the following.

voldisk clearimport
voldg init
voldg adddisk

Once the volume set is created you can use /sbin/advfs/advscan to detect
any ADVFS sets on the volume set and have it setup links in /etc/fdmns.

This worked for me with concatenated disks into a volume set. I also had
to use this to backup a set of disks that
were in an ASE cluster but had to stop clustering to do the backup which
meant the volume set had to be rebuilt and the ADVFS set advscan'd to
recreate the mountable sets.

(c) from Alpert, Debra [DAlpert_at_lifelinesys.com]

We experienced the behavior you describe at our site as well, on systems
running both Tru64 5.0a and 5.1. It may be that the same LSM mechanisms are
at work in version 5.0. We found that the problem became manifest after a
disk drive was moved or reseated while the system in question was down. Upon
reboot, the diskgroup which contained the moved disk appeared to have
vanished entirely from LSM. It seems that this the default behavior of the
auto-import feature in versions 5.X of Tru64.

The following steps restored the configuration:

voldg -f import $diskgroup
volume -f -g $diskgroup start

Warning messages will probably be issued because of the "f"orce option, but
in our case, sanity was restored nonetheless.

Hope this helps you resolve your problem.

(d) from MIKE WHOLF [MIKE_WHOLF_at_interliant.com]

I would suggest moving the LSM directory out of the way and then do a
volsetup without any options. That will do the LSM discovery by looking at
all the disks. Hopefully, there are several disks with the configuration
saved. I do suggest running volsave; however, I have never had to use it.



There you go. Thanks to everyone who replied.

Dennis

######################################
Dennis Macdonell
Systems Administrator
AUSLIG
mail: PO Box 2, Belconnen, ACT 2617
email: mcdonell_at_auslig.gov.au
ph: 61 2 6201 4326
fax: 61 2 6201 4377
######################################
Received on Fri Apr 27 2001 - 05:16:03 NZST

This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:42 NZDT