Disk sets: databases always stale after reboot?

Disk sets: databases always stale after reboot?

Post by Dale Ghen » Fri, 06 May 2005 03:21:48



On Solaris 10/x86 ... I have a disk set configured and a SMF profile
that's active and releases (metaset -s <setname> -r) the disk set on
system shutdown, and take (metaset -s <setname> -t) the set on boot up.

The problem is, is that every time after a reboot, the disk set won't
import because metaset complains that the databases for it are stale.
Exit code 66.

I thought, from reading the online docs, that one needs only to run
'metaset -r' to clear a set from the system cleanly. Am I missing something?

There is a second host (that is running) assigned to this disk set, but
it isn't doing anything with it while the first machine is rebooting and
attempting to take the disk set back.

I wish this were as easy and straight-forward as 'vxdg export', but alas.

/dale

 
 
 

Disk sets: databases always stale after reboot?

Post by Dale Ghen » Fri, 06 May 2005 03:34:41



> On Solaris 10/x86 ... I have a disk set configured and a SMF profile
> that's active and releases (metaset -s <setname> -r) the disk set on
> system shutdown, and take (metaset -s <setname> -t) the set on boot up.

replying here to my own post...

This setup is on a fiber channel SAN. Would I have to execute and
'luxadm reserve/release' commands on the devices in the disk set before
executing metaset commands on it?

/dale

 
 
 

1. metainit: hostname: stale databases

Hi all ....

I have a problem wich I'm quite unsurtain how to fix atm.
On a Sol7 machine - running mirror of OS disks - one of the main disks got
corrupted. In fact I didnt notice this at first - so by a remote restart it
simply would not boot. I then went to the machine and realized what had
happened - uh ..... I know - I know :-)

But - ok - since I had no replacement disk avail - I swapped the corrupt
disk from the corrupt one (no - I had'nt made dual boot alternatives) -
booted by cdrom into signle-user - commented out the loading of metadisk
from /etc/system and edited the vfstab to use the single disk again. This
went fine - even though I forgot some small things like those files
controlling the metadatabase (mddb.cf, md.tab etc)

Ok - now - I'm in the situation that I've put in the replacement disk - and
have partitioned it like the working one. So - well - since I now have a
more or less "clean" /etc/system file - I thought - well - lets create these
metadb again as if this was the initial setup. Did the "metadb -a -f -c 3
c0t0d0s7" and "metadb -a -c 3 c0t8d0s7". metadb command runs without
hitches. Fine ! - well - not quite. I then started to try to setup the
mirroring ..... and get this error: "metainit: {hostname}: stale databases"

Darn. I'm almost lost from ideas. The only one I'm now considering - but I
feel declined to try since I dont have any test-equip avail atm. is to do
the process ... kind of reversed.

boot single on cdrom.
rename the "backup" of /etc/system so all metadata info is back.
edit /etc/vfstab file to point to /dev/md/xxxx as before .....

But - well - I'm very unsurtain - since I obviously didnt do everything "by
the book" when I needed that system back up fast. (mddb.cf etc....)

Any suggestions ?

Yours, Sverre Larsson

2. Usage of filters in pppd

3. more raid fun: stale database

4. FTAM (OSI)

5. state databases in shared disk set

6. Unix Training

7. Stale NFS file handle even through reboots

8. Unknown compression method - cant get started.

9. removing stale file handle without a reboot?

10. Redhat 7.2 Cannot shutdown, always reboot.

11. ppp always fails after a reboot

12. Always reboot due to missing file .....