NAME

ds − (disk) stripe device interface

SYNOPSIS

ds? 

DESCRIPTION

The stripe device interface allows users to combine various block devices into one logical device.  Normally, this is used only for disk devices, allowing several disk partitions to be logically treated as a single partition.  Benefits of disk striping include elimination of the restriction that a file system reside in a single partition (or physical disk), enhanced throughput due to the parallelism available from having multiple disk arms and CCUs working on the same file system, and the possibility of better disk-drive load balancing. 

There are currently 256 stripe devices available. Each is referenced with a different minor device number (0-255).  By convention, the special files /dev/rds0 through /dev/rds255 are used to access the raw stripe devices.  The special files /dev/ds0 through /dev/ds255 are used to access the block stripe devices.  Each stripe device can combine up to 32 other block devices, such as disk partitions.  There is no requirement that the block devices be of the same size or physical layout, although such parameters may affect the efficiency of disk transfers. 

Before a stripe device can be accessed, a table that specifies the layout of the stripe device must be loaded into the memory of the DYNIX kernel.  (In particular, the stripe table must be loaded before mkfs(8), fsck(8), or mount(8) can be invoked on the stripe device, and should never be changed while the stripe device is mounted, or while the device is being accessed.)  Normally, the script /etc/rc and init(8) invoke putst(8) in order to load all the stripe tables at reboot time.  Alternately, the table loading may be done manually with the program putst.  The layout of this table is specified in the file /usr/include/sys/stripe.h, and includes the major/minor device numbers of the component block devices, information on the number and size of the component blocks, and the stripe block size.

Normal users should make the stripe table using newst(8), which automatically handles all the low-level details.  Make sure the stripe table is loaded by an invocation of putst in /etc/rc at every reboot. 

Though it is preferable to use the utilities putst(8) and getst(8), there are two ioctl’s available for loading and retrieving the stripe table information.  These basic ioctl’s use the structure defined in <sys/stripe.h>:

struct stripe_dev {
dev_tst_dev[MAX_STRIPE_PARTITIONS];
struct{
longst_start;/∗ starting block of this stripe ∗/
longst_size;/∗ size (blocks) of each partition ∗/
intst_ndev;/∗ number of devices in this stripe ∗/
intst_block;/∗ stripe block size ∗/
} st_s[MAX_STRIPE_PARTITIONS];
longst_total_size;/∗ total size of the device- blocks ∗/
};
 typedef struct stripe_dev stripe_t;

Usage for stripe-related ioctl’s is as follows:

#include <sys/ioctl.h>
#include <sys/stripe.h>

ioctl(fildes, code, (char ∗) &tbl_ptr)
stripe_t ∗tbl_ptr;

The applicable codes are:

STPUTTABLESet up a stripe table in the kernel according to the pointed-to stripe_dev structure. 

STGETTABLECopy the proper stripe table information into the pointed-to stripe_dev structure. 

The device driver comes with a DYNIX binary configuration file, conf_stripe.c, which contains driver parameters to be statically tuned in the DYNIX kernel.  Since the driver implementation shares a local pool of type struct buf both the size of this pool ( nstripebufs ) and the number of elements from it dedicated to any one I/O request ( stripe_maxbufs ) are declared and initialized in this source file and may be adjusted for your specific site needs. 

FILES

/dev/rds? 
/dev/ds?
/etc/stripecap

SEE ALSO

putst(8), getst(8), newst(8), stripecap(5)

CAVEATS

For security reasons, you must be superuser and be the only one accessing a stripe partition to successfully execute the STPUTTABLE ioctl. Also, the component partition devices must be ordered by size, in descending order.  Stripe block sizes must be a minimum of 16 or a multiple thereof (representing 8kbytes).  Stripe section sizes must be a multiple of the that section’s stripe block size and section start offsets are expected to contain no gaps.  Finally, the total size of the entire stripe partition must be less than 2 gigabytes.  This is currently a DYNIX addressing limitation. 

Be careful that composit partitions do not overlap on the same device or data corruption may result from their use.  Likewise, care must be taken to ensure that the same configuration is repeatedly used to access the stripe partition.  Otherwise, previously written data may appear to be corrupt and subsequently get corrupted. 

Performance may be reduced if partitions in the stripe partition are not on distict disk drives.  It is also recommended that they be located on distinct disk controller channels.  Likewise, it is best for partitions to be of equal lengths on identical drives and controllers, although not necessary. 

Stripe partitions cannot be used for the root file system, since the DYNIX kernel and standalone utilities do not know the stripe partitions layout.  This information is not available until the root file system is being used to execute putst.  Similarly, do not use it as a swap partition. 

The stripe partition’s data may be corrupted if one of its composit partitions is written to directly. 

DYNIX