DiskSuite: Create the metadb replica databases

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

Veritas: Mirroring The Root Disk

Create the mirrors
1. Give veritas control of a disk to create the mirror on
/usr/lib/vxvm/bin/vxdisksetup -i solaris-disk-name

2. Add the new disk to the rootdg disk group and give it a veritas name
vxdg -g rootdg adddisk rootmirror=solaris-disk-name
3. Mirror the root partition
/etc/vx/bin/vxrootmir rootmirror

4. Mirror the swap space
vxassist -g rootdg mirror swapvol rootmirror
5. Mirror the var volume
vxassist -g rootdg mirror var rootmirror
6. Mirror the opt volume
vxassist -g rootdg mirror opt rootmirror
Ensure that each volume on the rootdisk is tied to a hard partition
1. Identify which hard partition on the disk you wish to tie volume to by checking out /etc/vfstab. See what lines volume manager commented out.

2. Identify which subdisk each volume is on that you want to tie back to the hard partition

3. Run the command to link the subdisk to a hard partition
a. for swap
vxmksdpart –g rootdg subdisk hard-partition 0x03 0x01
b. for var
vxmksdpart –g rootdg subdisk hard-partition 0x07 0x00
c. for opt
vxmksdpart –g rootdg subdisk hard-partition 0x00 0x00
d. for /
vxmksdpart –g rootdg subdisk hard-partition 0x02 0x00

Veritas: Remove A Disk Group

1. remove any volumes from the disks
a. vxassist –g disk-group remove volume volume-name
b. repeat the above procedure for each volume on the disk

2. remove disks from the disk group
a. vxdg –g disk-group rmdisk vxvm-disk-name
b. repeat the above procedure until there is one disk remaining in the disk group; you cannot remove the last disk from a disk group. At this point you will just need to remove the disk group itself.

3. remove the disk group
a. vxdg destroy disk-group

Veritas: Commands To Defrag The File System

1. Some options worth noting
a. –D : report on directory fragmentation
b. –E : report on extent reorganization
c. –d : defragment the directory structure
d. –e : reorganize extent structure
e. –s : report with a summary of work completed
f. –v : report on reorganization activity

2. Example commands
/usr/lib/fs/vxfs/fsadm –F vxfs –D –E –s –v –d –e mount-point
/usr/lib/fs/vxfs/fsadm –F vxfs –s –d –e mount-point

Veritas: Volume Relayout

1. It is possible to relayout volumes/filesystems on the fly with veritas
# vxassist –g disk-group-name relayout volume-name
layout=layout-type ncol=number-of-columns alloc=”disks
to use” stripeunit=stripe-width

b. where alloc defines the disks to build the new layout on, ncol is the number columns to use, stripeunit is the size of the stripes (stripeunit is optional, default is 128), and where layout is the layout you are going to migrate to.
2. to check the relayout status vxrelayout status volume-name
3. to restart a hung or failed relayout vxrelayout start volume-name
4. to reverse a relayout vxrelayout reverse volume-name
5. after a relayout completes if you need to evacuate a disk to complete a new stripe set, or want to migrate data from one disk to a new disk vxevac –g disk-group-name current-disk new-disk
a. example:
vxevac –g testdg testdg01 testdg02
(this would move all data on testdg01 to testdg02)

How to mount and unmount a drive in linux

How To Mount A Drive In Linux

mount /dev/partitionId /some/mounting/point
eg. #mount /dev/sda2 /mnt

The mounting point path must already be created with proper permissions. So a more likely flow of commands would be

mkdir /some/mounting/point
chmod 777 /some/mounting/point
mount /dev/partitionId /some/mounting/point

How To Unmount A Drive In Linux

umount /dev/partitionId
eg. #umount /mnt

This command is very easy to type wrong. It is NOT unmount. Take another closer look if thats what you saw at first. It is umount — no n here!