SUMMARY [problems with SDS metadb state replicas]

	My metadb state replicas looked like this;

a        u         16              1034            /dev/dsk/c1t0d0s7
a        u         1050            1034            /dev/dsk/c1t0d0s7
a        u         2084            1034            /dev/dsk/c1t0d0s7
a        u         16              1034            /dev/dsk/c1t1d0s7
a        u         1050            1034            /dev/dsk/c1t1d0s7
a        u         2084            1034            /dev/dsk/c1t1d0s7

	After a reboot, they now look like this;

a m  p  luo        16              1034            /dev/dsk/c1t0d0s7
a    p  luo        1050            1034            /dev/dsk/c1t0d0s7
a    p  luo        16              1034            /dev/dsk/c1t0d0s7
a    p  luo        1050            1034            /dev/dsk/c1t1d0s7
a    p  luo        16              1034            /dev/dsk/c1t1d0s7
a    p  luo        1050            1034            /dev/dsk/c1t1d0s7

	So to answer my question, the 'm', 'p', 'l' and 'o' flags are
all set at boot time. Seemingly, as long as there are no flags with 
capital letters (see `metadb -i`), things should be OK.

	Thanks to those who replied. I accidentally deleted your replies, but I 
had 2 responses, both of which assured me I was not hosed.

	Cheers!

	Chris


> 
> I made an error while replacing a disk in a SDS 4.2 raid-1
> mirror this morning. Disk 'c1t0d0' was showing intermittent
> errors, so I got a new disk and started the replacement process.
> 
> I metadetach'd the running sds devices on c1t0d0 from their
> running mirrors. I then made my mistake; I deleted the state
> db replicas from c1t1d0 and not c1t0d0 as I should have
> (metadb -d /dev/dsk/c1t1d0s7).
> 
> I did not realize my mistake until after I replaced the bad disk
> (c1t0d0) and tried to create the state replicas on it. At the time,
> 'metadb -i' was showing that the state replicas on c1t0d0s7 were in
> 'W' state (write errors).
> 
> I have backed out of my mistake by placing the original c1t0d0 disk
> (the one with intermittent errors) back in the system. I then
> re-created the accidentally deleted state db's on c1t1d0s7. Once
> created the state db's on c1t1d0s7 looked like this;
> 
> a        u         16              1034            /dev/dsk/c1t1d0s7
> a        u         1050            1034            /dev/dsk/c1t1d0s7
> a        u         2084            1034            /dev/dsk/c1t1d0s7
> 
> This didn't look too bad, so I then deleted the state db's on c1t0d0s7
> and re-created them. metadb now shows the two sets of state db's as;
> 
> a        u         16              1034            /dev/dsk/c1t0d0s7
> a        u         1050            1034            /dev/dsk/c1t0d0s7
> a        u         2084            1034            /dev/dsk/c1t0d0s7
> a        u         16              1034            /dev/dsk/c1t1d0s7
> a        u         1050            1034            /dev/dsk/c1t1d0s7
> a        u         2084            1034            /dev/dsk/c1t1d0s7
> 
> There are however flags missing from the state replicas. An identical
> machine I have has the following output from metadb;
> 
> a m  p  luo        16              1034            /dev/dsk/c1t0d0s7
> a    p  luo        1050            1034            /dev/dsk/c1t0d0s7
> a    p  luo        16              1034            /dev/dsk/c1t0d0s7
> a    p  luo        1050            1034            /dev/dsk/c1t1d0s7
> a    p  luo        16              1034            /dev/dsk/c1t1d0s7
> a    p  luo        1050            1034            /dev/dsk/c1t1d0s7
> 
> MY QUESTION;
> 
> Is there anything wrong with my state db's? ie: Am I screwed if I am
> missing the 'm, p, l and o' flags from metadb output?
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers