Step 3:
Because you must have at least two metadb replicas available for the
system to work, I suggect that your chosen slice have two metadb
replicas in it, on each drive. That way you have four metadbs in total
and you can lose either drive and keep running.
su to root and set up your path for sanity …
PATH=/usr/sbin:/usr/bin:/usr/opt/SUNWmd/sbin;export PATH
and then create the metadbs in /dev/dsk/c0t1d0s4 and /dev/dsk/c0t3d0s4
and make sure your boot drive has the first metadb replica db …
# metadb -a -c 2 -f /dev/dsk/c0t3d0s4 /dev/dsk/c0t1d0s4
and that creates the four needed dbs as ( note “-c 2” ) 2 dbs per slice.
Check your /etc/system file and you will see some new stuff at the
bottom :
* Begin MDD database info (do not edit)
set md:mddb_bootlist1=”sd:28:16 sd:28:1050 sd:12:16 sd:12:1050″
* End MDD database info (do not edit)
At this point, if you want, you can reboot. You will see a stack of
WARNING messages, not errors, WARNINGS only ( hand waving again ) about
a stack of failures due to raid this and trans that not loading. Ignore
this. Everyone has fits when they see it thinking it means some
catastrophe has happened to their system. Not yet. :) If you use
metadb -i you should see
# metadb -i
flags first blk block count
a m p luo 16 1034 /dev/dsk/c0t3d0s4
a p luo 1050 1034 /dev/dsk/c0t3d0s4
a p luo 16 1034 /dev/dsk/c0t1d0s4
a p luo 1050 1034 /dev/dsk/c0t1d0s4
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/opt/SUNWmd/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