UNIX Commands

This is not meant to be an exhaustive list of UNIX commands, there's plenty of sites out there that will give you them. Rather, it's a list of some of the commands that I find useful when working with UNIX Storage. Most of these commands will work with Linux too.

The UNIX interface

First, what should be some basic ideas about how to interface with UNIX. Be aware that some Utility commands are shell dependent. These ones should work for the ksh shell. Every user has their own environment that contains variables that control your session, such as home directory, shell and paths to commands. Use the command 'env' to see what variables are set for your session.

To make temporary changes to your environment use the set command as above 'set -o vi' or 'set history=50' (this increases your history record from the 20 default).

To make permanent changes you need to update the .profile dataset in your home directory. You can see this file if you use the ls -al command.

The vi Editor

This leads to Unix editing. The vi editor is pretty much universal and is powerful once you learn to use it. Some less well known command mode tips are: -


One of the challenges with TSM backups is network connectivity. These network commands are worth trying to track down a problem, before you go and find someone who knows what they are doing.

UNIX configuration

UNIX File System commands

The lspv command with various flags will list physical volumes and various attributes, not all of which are relevant in these days of RAID arrays and virtualisation. Try man lspv for an explanation.

The lsvg command for Volume Groups is relevant for HACMP configurations where you need to know the filespaces that are assigned to to floating HACMP volume groups.

Checking installed versions of software

The Linux command for this is not the same as Unix, to check installed tivoli software on AIX use

lsppp l- *tivoli*

and on Linux (RHEL) use this command. The -i switch means the search will not be case sensitive

rpm -qa | grep -i tivoli

Using VMSTAT and IOSTAT to check for disk problems

The VMSTAT command can be used to check for disk bottlenecks by looking at the block I/O. A command with typical parameters would be

vmstat -ItW 10

The -ItW means show an IO view, add a timestamp on the end of each time and display the count of waiting threads. The '10' means run the command every 10 seconds. The commands has loads of other parameters as well as these three. Typical output looks like this.

The first 4 columns are the most interesting;
'r' is the runber of 'runnable' kernel threads, including active and waiting
'b' is the number of threads that are blocked waiting for IO on filesystems
'p' is the number of threads waiting for IO on raw logical volumes
'w' is the number of threads waiting for IO operations

You want to see Values of 0 in the 'b' 'p' and 'w' columns. If you see values greater than 0, this indicates the I/O threads that are blocked but don't worry about occasional high values, this is only an issue if the values are consistently high.

IOSTAT output can be used to check for Disk performance bottlenecks, suitable commands for AIX and Linux respectively are

iostat -DlT 10
iostat -xtk sinterval iterations

This command will return loads of data for every online disk, split into 4 sections; xfers, read, write and queue.
The qfull column in the queue section indicates how many times an i/o request was blocked because the OS queue for the disk was full. Consistently high numbers are bad and is an indication that there isn’t enough parallelism at the OS layer, or it might be an indication that queue depth is incorrectly set. Most IBM disk subsystems have a default queue depth of 32, the XIV can be set at 64, but non IBM disk subsystems have a default value of 1. For parallelism it can be better to have 10 100GB LUNS rather than 1 1TB LUN.
The tps column under xfers tells you hom many IOs per second (IOPS) are going to each disk, and typical Fibre Channel or SAS IOPS should be about 150, SATA about 90 IOPS, but SSDs should be in the thousands.
The read and write columns are service times, and TSM likes service values less than 5ms for log and DB reads or writes.

UNIX and Linux

Lascon latest major updates

Welcome to Lascon Storage. This site provides hints and tips on how to manage your data, strategic advice and news items.