unixpowered.com

Create simple striped pool:
zpool create [pool_name] [device] [device] ...
zpool create datapool c5t433127A900011C370000C00003210000d0 c5t433127B4001031250000900000540000d0

Create mirrored pool:
zpool create [pool_name] mirror [device] [device] ...
zpool create datapool mirror c5t433127A900011C370000C00003210000d0 c5t433127B4001031250000900000540000d0

Create Raid-Z pool:
zpool create [pool_name] raidz [device] [device] [device] ...
zpool create datapool raidz c5t433127A900011C370000C00003210000d0 c5t433127B4001031250000900000540000d0 c5t439257C4000019250000900000540000d0

Transform simple pool to a mirror:
zpool create [pool_name] [device]
zpool attach [pool_name] [existing_device] [new_device]
zpool create datapool c5t433127A900011C370000C00003210000d0
zpool attach datapool c5t433127A900011C370000C00003210000d0 c5t433127B4001031250000900000540000d0

Expand simple pool:
zpool create [pool_name] [device]
zpool add [pool_name] [new_device]
zpool create datapool c5t433127A900011C370000C00003210000d0
zpool add datapool c5t433127B4001031250000900000540000d0

Expand mirrored pool by attaching additional mirror:
zpool add [pool_name] mirror [new_device] [new_device]
zpool add datapool mirror c5t433127A900011C370000C00003460000d0 c5t433127B400011C370000C00003410000d0

Replace device in a pool:
zpool replace [pool_name] [old_device] [new_device]
zpool replace datapool c5t433127A900011C370000C00003410000d0 c5t433127B4001031250000900000540000d0

Destroy pool:
zpool destroy [pool_name]
zpool destroy datapool

Set pool mountpoint:
zfs set mountpoint=/path [pool_name]
zfs set mountpoint=/export/zfs datapool

Display configured pools:
zpool list
zpool list

Display pool status info:
zpool status [-v] [pool_name]
zpool status -v datapool

Display pool I/O statistics:
zpool iostat [pool_name]
zpool iostat datapool

Display pool command history:
zpool history [pool_name]
zpool history datapool

Export a pool:
zpool export [pool_name]
zpool export datapool

Import a pool:
zpool import [pool_name]
zpool import datapool

Create a filesystem:
zfs create [pool_name]/[fs_name]
zfs create datapool/filesystem

Destroy a filesystem:
zfs destroy [pool_name]/[fs_name]
zfs destroy datapool/filesystem

Rename a filesystem:
zfs rename [pool_name]/[fs_name] [pool_name]/[fs_name]
zfs rename datapool/filesystem datapool/newfilesystem

Move a filesystem:
zfs rename [pool_name]/[fs_name] [pool_name]/[fs_name]/[fs_name]
zfs rename datapool/filesystem datapool/users/filesystem

Display properties of a filesystem:
zfs get all [pool_name]/[fs_name]
zfs get all datapool/filesystem

Make a snapshot:
zfs snapshot [pool_name]/[fs_name]@[time]
zfs snapshot datapool/filesystem@friday

Roll back filesystem to its snapshot:
zfs rollback [pool_name]/[fs_name]@[time]
zfs rollback datapool/filesystem@friday

Clone a filesystem:
zfs snapshot [pool_name]/[fs_name]@[time]
zfs clone [pool_name]/[fs_name]@[time] [pool_name]/[fs_name]
zfs snapshot datapool/filesystem@today
zfs clone datapool/filesystem@today datapool/filesystemclone

Backup filesystem to a file:
zfs send [pool_name]/[fs_name] > /path/to/file
zfs send datapool/filesystem@friday > /tmp/filesystem.bkp

Restore filesystem from a file:
zfs receive [pool_name]/[fs_name] < /path/to/file
zfs receive datapool/restoredfilesystem < /tmp/filesystem.bkp

Create ZFS volume:
zfs create -V [size] [pool_name]/[vol_name]
zfs create -V 100mb datapool/zvolume
newfs /dev/zvol/dsk/datapool/zvolume Continue Reading

You have a SVM mirror and you need to grow it. Online. All steps are straight forward except for the last one. So, in a nutshell:

1. Grow sizes of both submirror LUN’s on SAN
2. Detach the first submirror metadevice
3. Clear the submirror metadevice
4. Make the system see new LUN size
5. Recreate the submirror metadevice, attach it to the mirror and let it sync
6. Repeat the above for the second submirror
7. Not so obvious step
8. Grow the filesystem

You have a mirror metadevice d200 consisting of submirrors d201 and d202. Both submirrors are sliced in such way that all space is allocated in slice 0. At this point both LUN’s should be already grown, but you need to make the system to see the size increase. Here is what d201, one of the submirrors of d200, should look like:

bash-3.00# metastat d201
d201: Submirror of d200
State: Okay
Size: 2064384 blocks (1008 MB)
Stripe 0:
Device Start Block Dbase State Reloc Hot Spare
/dev/dsk/c5t511714A510011C370000C00003410000d0s0 0 No Okay Yes

First, detach d201 from its parent and clear it:

bash-3.00# metadetach d200 d201
bash-3.00# metaclear d201

The next step is likely to alter the LUN slice configuration, so make sure you have it noted.

You need to run format command to get the system to see the grown LUN. So, run format then select type and then select Autoconfigure. At this point format should be reporting the new LUN size. Make sure your slice configuration is correct and that all the new space is tacked onto the end of correct slice. In this case, it’s slice 0.

Now recreate d201, attach it to d200 and let the mirror sync. When checking status of d200 note that overall mirror size is still the same but the size of d201 increased:

bash-3.00# metastat d200
d200: Mirror
Submirror 0: d202
State: Okay
Submirror 1: d201
State: Okay
Pass: 1
Read option: roundrobin (default)
Write option: parallel (default)
Size: 2064384 blocks (1008 MB)

d202: Submirror of d200
State: Okay
Size: 2064384 blocks (1008 MB)
Stripe 0:
Device                                             Start Block  Dbase        State Reloc Hot Spare
/dev/dsk/c5t511714A510011C370000C00003460000d0s0          0     No            Okay   Yes

d201: Submirror of d200
State: Okay
Size: 4128768 blocks (2.0 GB)
Stripe 0:
Device                                             Start Block  Dbase        State Reloc Hot Spare
/dev/dsk/c5t511714A510011C370000C00003410000d0s0          0     No            Okay   Yes


Now repeat the same process with d202. After you are done you will have both submirrors bigger, but the size of overall mirror will still be the same:

bash-3.00# metastat d200
d200: Mirror
Submirror 0: d201
State: Okay
Submirror 1: d202
State: Okay
Pass: 1
Read option: roundrobin (default)
Write option: parallel (default)
Size: 2064384 blocks (1008 MB)

d201: Submirror of d200
State: Okay
Size: 4128768 blocks (2.0 GB)
Stripe 0:
Device Start Block Dbase State Reloc Hot Spare
/dev/dsk/c5t511714A510011C370000C00003410000d0s0 0 No Okay Yes

d202: Submirror of d200
State: Okay
Size: 4161536 blocks (2.0 GB)
Stripe 0:
Device Start Block Dbase State Reloc Hot Spare
/dev/dsk/c5t511714A510011C370000C00003460000d0s0 0 No Okay Yes

Now comes the “Not so obvious” step. In order to increase overall mirror size you need to run metattach on the mirror itself:

bash-3.00# metattach d200
bash-3.00# metastat d200
d200: Mirror
Submirror 0: d201
State: Okay
Submirror 1: d202
State: Okay
Pass: 1
Read option: roundrobin (default)
Write option: parallel (default)
Size: 4128768 blocks (2.0 GB)

This will grow the size of the entire mirror to the size of submirror devices. Now you can grow the filesystem on it without unmounting it. Keep in mind that for the duration of growfs command there will be no writes to the volume.

bash-3.00# growfs -M /export/home/users /dev/md/rdsk/d200
/dev/md/rdsk/d200: 4128768 sectors in 126 cylinders of 128 tracks, 256 sectors
2016.0MB in 63 cyl groups (2 c/g, 32.00MB/g, 15040 i/g)
super-block backups (for fsck -F ufs -o b=#) at:
32, 65824, 131616, 197408, 263200, 328992, 394784, 460576, 526368, 592160,
3487008, 3552800, 3618592, 3684384, 3750176, 3815968, 3881760, 3947552,
4013344, 4079136

That’s all there is to it. The “Not so obvious” step is mentioned in the metattach man page. But unless you do this stuff every day, this very useful piece of information can be easily forgotten. Continue Reading

I was configuring MPxIO on Sun Fire V490. After issuing stmsboot -e command and rebooting the server, internal disks were under MPxIO’s control.

This was not something I wanted and I needed to disable it. In order to do so I had to edit /kernel/drv/fp.conf file and tell Solaris not to enable MPxIO on internal disks. So I added the following line at the end of fp.conf file:

name="fp" parent="/pci@8,600000/SUNW,qlc@4" port=0 mpxio-disable="yes";

This line tells Solaris to disable MPxIO on port 0 for all devices whose parent device is /pci@8,600000/SUNW,qlc@4. Of course, similar line should be added for all HBA’s and ports you do not want to have under MPxIO’s control. You can get the parent device from your /var/adm/messages file or from device links pointing to the internal disks. Here is a partial list of device links:
<—————–SNIP—————->
lrwxrwxrwx 1 root other 70 Jun 12 11:50 c1t0d0s0 -> ../../devices/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w2100002037c3e2ef,0:a
lrwxrwxrwx 1 root other 70 Jun 12 11:50 c1t0d0s1 -> ../../devices/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w2100002037c3e2ef,0:b
lrwxrwxrwx 1 root other 70 Jun 12 11:50 c1t0d0s2 -> ../../devices/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w2100002037c3e2ef,0:c
lrwxrwxrwx 1 root other 70 Jun 12 11:50 c1t0d0s3 -> ../../devices/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w2100002037c3e2ef,0:d
lrwxrwxrwx 1 root other 70 Jun 12 11:50 c1t0d0s4 -> ../../devices/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w2100002037c3e2ef,0:e
lrwxrwxrwx 1 root other 70 Jun 12 11:50 c1t0d0s5 -> ../../devices/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w2100002037c3e2ef,0:f
lrwxrwxrwx 1 root other 70 Jun 12 11:50 c1t0d0s6 -> ../../devices/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w2100002037c3e2ef,0:g
lrwxrwxrwx 1 root other 70 Jun 12 11:50 c1t0d0s7 -> ../../devices/pci@8,600000/SUNW,qlc@4/fp@0,0/ssd@w2100002037c3e2ef,0:h
<—————–SNIP—————-> Continue Reading

I came across fcinfo command reading some man page. So, I decided to see what kind of useful fibre channel information it could give me. It turns out fcinfo knows quite a bit.

We can list all local fibre channel ports:

bash-3.00# fcinfo hba-port
HBA Port WWN: 21000003ba16dbd2
OS Device Name: /dev/cfg/c1
Manufacturer: QLogic Corp.
Model: 2200
Firmware Version: 2.1.144
FCode/BIOS Version: ISP2200 FC-AL Host Adapter Driver: 1.12 01/01/16
Type: L-port
State: online
Supported Speeds: 1Gb
Current Speed: 1Gb
Node WWN: 20000003ba16dbd2
HBA Port WWN: 2100001b320e3853
OS Device Name: /dev/cfg/c3
Manufacturer: QLogic Corp.
Model: QLA2462
Firmware Version: 4.0.27
FCode/BIOS Version: QLA2462 Host Adapter Driver(SPARC): 1.24 11/15/06
Type: N-port
State: online
Supported Speeds: 1Gb 2Gb 4Gb
Current Speed: 2Gb
Node WWN: 2000001b320e3853
HBA Port WWN: 2101001b322e3853
OS Device Name: /dev/cfg/c4
Manufacturer: QLogic Corp.
Model: QLA2462
Firmware Version: 4.0.27
FCode/BIOS Version: QLA2462 Host Adapter Driver(SPARC): 1.24 11/15/06
Type: N-port
State: online
Supported Speeds: 1Gb 2Gb 4Gb
Current Speed: 2Gb
Node WWN: 2001001b322e3853

We can take a look what remote ports are seen by particular local fibre channel port, in this case 2100001b320e3853:

bash-3.00# fcinfo remote-port -p 2100001b320e3853
Remote Port WWN: 100000e00216aef3
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 100000e01124b88f
Remote Port WWN: 50001fe15003b384
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 50001fe15037e759
Remote Port WWN: 100000e0022744f3
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 100000e0020744f3
Remote Port WWN: 50001fe150216de9
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 50001fe11025bb53
Remote Port WWN: 100000e00228f492
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 100000e00208f492
Remote Port WWN: 50001fe15076b59b
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 50001fe15037e759
Remote Port WWN: 50001fe150216ded
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 50001fe11025bb53

Here, we get link statistics for remote fibre channel device whose WWN is 100000e0020744f3:

bash-3.00# fcinfo remote-port -l -p 2100001b320e3853 100000e0020744f3
Remote Port WWN: 100000e0022744f3
Active FC4 Types: SCSI
SCSI Target: unknown
Node WWN: 100000e0020744f3
Link Error Statistics:
Link Failure Count: 0
Loss of Sync Count: 0
Loss of Signal Count: 0
Primitive Seq Protocol Error Count: 0
Invalid Tx Word Count: 0
Invalid CRC Count: 0

We can also get link statistics and SCSI target information for all remote fibre channel devices see on local port whose WWN is 2100001b320e3853:

bash-3.00# fcinfo remote-port -sl -p 2100001b320e3853
Remote Port WWN: 100000e00216aef3
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 100000e01124b88f
Link Error Statistics:
Link Failure Count: 0
Loss of Sync Count: 0
Loss of Signal Count: 0
Primitive Seq Protocol Error Count: 0
Invalid Tx Word Count: 0
Invalid CRC Count: 0
LUN: 0
Vendor: HP
Product: MSL6000 Series
OS Device Name: /devices/pci@8,600000/SUNW,qlc@1/fp@0,0/sgen@w100000e00216aef3,0
LUN: 1
Vendor: HP
Product: Ultrium 2-SCSI
OS Device Name: /dev/rmt/2n
Remote Port WWN: 50001fe15003b384
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 50001fe15037e759
Link Error Statistics:
Link Failure Count: 0
Loss of Sync Count: 0
Loss of Signal Count: 0
Primitive Seq Protocol Error Count: 0
Invalid Tx Word Count: 0
Invalid CRC Count: 0
LUN: 0
Vendor: COMPAQ
Product: HSV111 (C)COMPAQ
OS Device Name: Unknown
LUN: 1
Vendor: COMPAQ
Product: HSV111 (C)COMPAQ
OS Device Name: /dev/rdsk/c5t600508B4001031250000900000540000d0s2
Remote Port WWN: 100000e0022744f3
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 100000e0020744f3
Link Error Statistics:
Link Failure Count: 0
Loss of Sync Count: 0
Loss of Signal Count: 0
Primitive Seq Protocol Error Count: 0
Invalid Tx Word Count: 0
Invalid CRC Count: 0
LUN: 0
Vendor: HP
Product: MSL6000 Series
OS Device Name: /devices/pci@8,600000/SUNW,qlc@1/fp@0,0/sgen@w100000e0022744f3,0
LUN: 1
Vendor: HP
Product: Ultrium 2-SCSI
OS Device Name: /dev/rmt/1n
LUN: 2
Vendor: HP
Product: Ultrium 2-SCSI
OS Device Name: /dev/rmt/0n
Remote Port WWN: 50001fe150216de9
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 50001fe11025bb53
Link Error Statistics:
Link Failure Count: 0
Loss of Sync Count: 0
Loss of Signal Count: 0
Primitive Seq Protocol Error Count: 0
Invalid Tx Word Count: 0
Invalid CRC Count: 0
LUN: 0
Vendor: COMPAQ
Product: HSV111 (C)COMPAQ
OS Device Name: Unknown
LUN: 1
Vendor: COMPAQ
Product: HSV111 (C)COMPAQ
OS Device Name: /dev/rdsk/c5t600508B400011C370000C00003210000d0s2
Remote Port WWN: 100000e00228f492
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 100000e00208f492
Link Error Statistics:
Link Failure Count: 0
Loss of Sync Count: 0
Loss of Signal Count: 0
Primitive Seq Protocol Error Count: 0
Invalid Tx Word Count: 0
Invalid CRC Count: 0
LUN: 0
Vendor: HP
Product: Ultrium 2-SCSI
OS Device Name: /dev/rmt/4n
LUN: 1
Vendor: HP
Product: Ultrium 2-SCSI
OS Device Name: /dev/rmt/3n
Remote Port WWN: 50001fe15076b59b
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 50001fe15037e759
Link Error Statistics:
Link Failure Count: 0
Loss of Sync Count: 0
Loss of Signal Count: 0
Primitive Seq Protocol Error Count: 0
Invalid Tx Word Count: 0
Invalid CRC Count: 0
LUN: 0
Vendor: COMPAQ
Product: HSV111 (C)COMPAQ
OS Device Name: Unknown
LUN: 1
Vendor: COMPAQ
Product: HSV111 (C)COMPAQ
OS Device Name: /dev/rdsk/c5t600508B4001031250000900000540000d0s2
Remote Port WWN: 50001fe150216ded
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 50001fe11025bb53
Link Error Statistics:
Link Failure Count: 0
Loss of Sync Count: 0
Loss of Signal Count: 0
Primitive Seq Protocol Error Count: 0
Invalid Tx Word Count: 0
Invalid CRC Count: 0
LUN: 0
Vendor: COMPAQ
Product: HSV111 (C)COMPAQ
OS Device Name: Unknown
LUN: 1
Vendor: COMPAQ
Product: HSV111 (C)COMPAQ
OS Device Name: /dev/rdsk/c5t600508B400011C370000C00003210000d0s2

This command is quite handy when troubleshooting fibre channel. Very cool… Continue Reading

If you have grown tired of having core files laying around all over the place you can manage them using coreadm command. You can set up system to save core files to a specific location.

First, here are the default core settings on a Solaris box:

bash-3.00# coreadm
global core file pattern:
global core file content: default
init core file pattern: core
init core file content: default
global core dumps: disabled
per-process core dumps: enabled
global setid core dumps: disabled
per-process setid core dumps: disabled
global core dump logging: disabled

Now, let’s configure the system to save init core files in /var/crash/cores in format EUID.execName.core:

bash-3.00# coreadm -i /var/crash/cores/%u.%f.core
bash-3.00# coreadm
global core file pattern:
global core file content: default
init core file pattern: /var/crash/cores/%u.%f.core
init core file content: default
global core dumps: disabled
per-process core dumps: enabled
global setid core dumps: disabled
per-process setid core dumps: disabled
global core dump logging: disabled

To test our setup, we can use gcore command.

bash-3.00# gcore -p 741
gcore: /var/crash/cores/0.bash.core dumped
bash-3.00# ls /var/crash/cores
0.bash.core hsperfdata_noaccess hsperfdata_root
bash-3.00#

Above, we generated core file for bash process with PID 741 run under effective UID 0. This should make the system tidier as far as core files are concerned. Continue Reading