SUMMARY: metadb output question



Thank you to everyone who replied. The overall consensus is that a reboot
will get the extra flags on the metadb output showing up as expected. But
the system is not performing in a degraded state until you reboot. So in
other words, don't reboot because of this, wait until you were going to do a
reboot for some other reason.

Original question:

Hello Sunmanagers, I recently added another mirrored slice d4, with
submirrors d14 and d24 to one of our systems with SVM. I created this slice
and another slice for meta-database replicas on untouched drives in the
server. At the end of the process I added the metadb replicas to there
slices like so:

metadb -a -c 3 c0t2d0s7 c4t2d0s7

This worked fine but when I do a metadb -i they show up without some of the
flags. Specifically these:

p - replica's location was patched in kernel
l - locator for this replica was read successfully
o - replica active prior to last mddb configuration change

Though they have the 'a' and 'u' flags. See output below. My question is
why? Is this something I need to worry about? How do I get the replica's
location patched in the kernel, etc..

Thank you for any help.


flags first blk block count
a m p luo 16 8192 /dev/dsk/c0t0d0s7
a p luo 8208 8192 /dev/dsk/c0t0d0s7
a p luo 16400 8192 /dev/dsk/c0t0d0s7
a p luo 16 8192 /dev/dsk/c0t1d0s7
a p luo 8208 8192 /dev/dsk/c0t1d0s7
a p luo 16400 8192 /dev/dsk/c0t1d0s7
a p luo 16 8192 /dev/dsk/c4t0d0s7
a p luo 8208 8192 /dev/dsk/c4t0d0s7
a p luo 16400 8192 /dev/dsk/c4t0d0s7
a p luo 16 8192 /dev/dsk/c4t1d0s7
a p luo 8208 8192 /dev/dsk/c4t1d0s7
a p luo 16400 8192 /dev/dsk/c4t1d0s7
a u 16 8192 /dev/dsk/c0t2d0s7
a u 8208 8192 /dev/dsk/c0t2d0s7
a u 16400 8192 /dev/dsk/c0t2d0s7
a u 16 8192 /dev/dsk/c4t2d0s7
a u 8208 8192 /dev/dsk/c4t2d0s7
a u 16400 8192 /dev/dsk/c4t2d0s7
r - replica does not have device relocation information
o - replica active prior to last mddb configuration change
u - replica is up to date
l - locator for this replica was read successfully
c - replica's location was in /etc/lvm/mddb.cf
p - replica's location was patched in kernel
m - replica is master, this is replica selected as input
W - replica has device write errors
a - replica is active, commits are occurring to this replica
M - replica had problem with master blocks
D - replica had problem with data blocks
F - replica had format problems
S - replica is too small to hold current data base
R - replica had device read errors


--
Romeo Theriault
<romeo.theriault@xxxxxxxxx>
_______________________________________________
sunmanagers mailing list
sunmanagers@xxxxxxxxxxxxxxx
http://www.sunmanagers.org/mailman/listinfo/sunmanagers



Relevant Pages

  • metadb -i ( and Document ID 18280 )
    ... a patch was applied that required a reboot. ... the system came up only in single-user mode saying: ... o - replica active prior to last mddb configuration change ... What does it mean if the re-added slices do not have the "p" flag ( ...
    (comp.unix.solaris)
  • metadb question
    ... metadb slice. ... replica to the same slice. ... between the procedures so the newly created replicas would get in sync ...
    (SunManagers)
  • Disksuite metadbs and HA 1.3 question
    ... Configuration: E4000 HA pair running Solaris 2.6, Disksuite 4.1, ... had a requirement for 3 arrays to distribute the metadbs. ... I'd like to delete the metadb replicas on the SSA114 but don't ... o - replica active prior to last mddb configuration change ...
    (SunManagers)
  • Re: Trying to make metadevices (soft partitions) available after reinstall
    ... >> c0d0s6 before metainit or is it possible that the db overwrites the data I ... Can metarecover find the soft parts even if the metadb ... > can't create metadevices without a replica to store the information in. ...
    (comp.unix.solaris)
  • Re: Trying to make metadevices (soft partitions) available after reinstall
    ... >> problem is that I did not use a dedicated slice for the replica when I ... > there before attempting to recreate the metadevice on the same slice. ... metadb: saustall: there are no existing databases ...
    (comp.unix.solaris)