BDSpro release 2.3 requires IRIX version 6.5 (or higher), BDSpro software, and NFS (version 2.0 or 3.0) installed on client and server systems. Server and client systems must also be at the current NFS and mount command overlays; server systems also require the current IRIX and networking overlays. Server and client systems must be connected to a HIPPI or other high-performance network. (See the BDSpro Release Notes for detailed requirements and instructions on software installation).

When selecting disks for use with BDS, choose a brand and model that excel in large sequential access operations. Disks with this characteristic offer better BDS performance and are therefore a better choice.

BDS installations that use fast-and-wide SCSI controllers with speeds of 20 MB per second (not UltraSCSI or Fiber Channel) must optimize the number of disks on a single SCSI bus. For example, a system containing four IBM drives with a transfer rate of 5 MB per second completely saturated a controller with a 20 MB per second transfer rate. The IBM drives provided by Silicon Graphics spin at about 7 MB per second on the outer zone and 5 MB per second on the inner zone. Assuming a transfer rate of 5 MB per second, it is apparent that 4 drives will completely saturate a single 20 MB per second controller.

Silicon Graphics provides SCSI boxes with an eight-drive capacity that are configured for one SCSI channel. This single channel configuration is inefficient for BDS— one channel can service only four of the disks before the maximum bandwidth is reached (4 disks @ 5 MB/disk/second = 20 MB/second). To optimize a factory-shipped SCSI box for BDSpro, reconfigure it from a single-channel to a two-channel device. A SCSI box with two channels offers twice the bandwidth and the additional channel can service the remaining four disks.

For maximum sequential performance with the minimum number of disks, purchase more controllers and use one controller for every three or four disks.

The limit that IRIX imposes on the maximum size of direct memory access (DMA) operations affects XFS, since direct I/O is a DMA operation. In IRIX 6.5, the default maximum DMA size is 4 MB. Frequently, this limit must be increased on BDSpro servers to achieve optimum performance.

To change the maximum DMA size, reset the maxdmasz variable using systune (see the systune(1M) reference page).

The values of maxdmasz are expressed in pages, which are 16 KB on 64-bit systems. Change these values to the size that you need, and then reconfigure and reboot the server.

BDSpro performance is highly dependent on the local performance of XFS and XLV on the server system; BDS is superfluous when local filesystem speed (or network speed) creates performance bottlenecks. You can often correct filesystem performance by properly configuring disks and by setting the correct size for direct memory access operations.

To measure local XFS performance, use lmdd commands similar to those shown below. If you determine that the results are inadequate for a BDS implementation, follow the tuning recommendations in “Tuning XLV Performance,” which follows.

This command creates testfile, a 500 MB file with a transfer size of 4MB; the return message confirms the new file:

server# lmdd of=/export/bds/local_xfs_file bs=4m move=500m direct=1
524.29 MB in 5.39 secs, 97.21 MB/sec

This command performs a direct read on testfile with a transfer size of 4MB; the return message shows the XFS transfer rate:

server# lmdd if=/export/bds/local_xfs_file bs=4m move=500m direct=1
524.29 MB in 3.79 secs, 138.15 MB/sec

XFS uses a logical volume manager, xlv, to stripe data across multiple disk drives. On striped disks, large XFS requests are split and sent to each disk in parallel. The high sequential performance of XFS is attributable to this parallelism. (See Chapter 7 of IRIX Admin: Disks and Filesystems for more information.)

The size of data transfers is an important consideration in planning logical volumes. For example, assume that a logical volume contains ten disks and the stripe size is 64 KB. In this case, transfers of 640 KB or larger are required to get all drives running simultaneously. If the data transfer size is 320 KB, only five drives are active in an I/O operation. Because only half of the available disks are used, a transfer size of 320 KB is very inefficient, reducing the total performance by half. With proper striping of logical volumes, however, you can maximize disk performance.

Disk Striping Fundamentals

The xlv_make utility stripes the disks in a logical volume. By default, xlv_make divides the disk into tracks and uses one track from each disk in rotation to create a stripe. The amount of data that xlv_make allocates on a single drive before going to the next is called the stripe unit. The stripe unit and the number of disks in the logical volume determine the stripe width, or

stripe width = stripe unit × number of disks

Figure 2-1 illustrates a logical volume containing four disks. Notice from this figure that the stripe unit is set to two tracks instead of one (the default stripe unit size). If we assume a track size of 100 KB (track size is set by disk manufacturers), the stripe width for this logical volume is 800 KB.

Figure 2-1. Effects of the Stripe Unit and Disk Number on Stripe Width

Table 2-2 shows the performance for BDSpro (version 2.0) using IBM drives with a 2 GB capacity and a HIPPI network. Three disks were configured on each controller; the transfer size was set to the stripe width size. Notice from Table 2-2 that BDS writes are significantly slower than XFS writes when write buffering is not used.