dt Test Recommendations

Test Considerations

Oftentimes, folks ask what is the best dt command lines to use. The answer usually depends what you are trying to test, but here are a few guidelines:

General Test Options

The following are options to consider for any type of device under test:
Choose a non-repeating data pattern or a prefix to create uniqueness:
Vary the I/O sizes, testing up to the maximum size supported:
For sequential I/O, consider testing both forward and reverse directions:
For random access devices, test both sequential and random I/O:
To generate high I/O loads, consider using POSIX AIO or multiple processes:
For extended test runs, select either multiple passes or specify a runtime:
Note: Please use AIO's in lieu of multiple processes to reduce system resource consumption. AIO's are very similar to multiple threads for generating heavy I/O load, except the POSIX AIO subsystem is utilized to queue multiple reads and writes.

File System Testing

Here are a few options to consider for file system testing:
Select multiple processes to create multiple files.
Select I/O sizes to test byte boundaries and cross block boundaries:
To defeat the effect of the file system buffer cache, use:
To force buffer cache to invalidate its' cache for this file system:
Reducing the buffer cache size will help decrease it's buffering effect.

Direct Disk Testing

Direct disk access is commonly referred to as raw (character) device testing on Unix based systems. Here are options to consider for raw testing:
Select multiple slices for heavier load and faster testing:
Enable POSIX Asynchronous I/O (AIO) to generate higher I/O loads:
Note: Linux only provides a block DSF, so DIO or raw(8) is recommended).

Shared (raw) Disk Testing

When performing shared concurrent disk testing from multiple hosts consider:
Divide the disk capacity up into multiple slices then choose slice:
Ensure each block has a unique prefix to track the writing host:
Encode the logical block address (LBA) in each block to aid w/corruptions:

Performance Testing

Best performance will be realized with large block sizes:
Queuing multiple I/O requests will provide better performance:
Best performance will be realized with data verification disabled:

Monitoring I/O Progress

A feature was added for detecting and reporting slow or no I/O progress. This feature is very useful for storage failover testing, since it lets you know how long it takes for I/O to resume. It can also be helpful for reporting hung I/O, assuming the required signal (SIGALRM) can be delivered to dt.
Two options control what's called the "no-progress I/O" feature:
What operations are monitored?

Trouble-Shooting Aids

There are a couple of options to help with troubleshooting problems:
To determine when a block was written, blocks can be timestamped:
For file system testing, keeping a corrupted file for analysis is helpful:
To report previous I/O information and data on data corruptions:
Executing an external script during errors can be helpful:
Enabling program debug information can be helpful:
For long running tests, you may wish to emit a keepalive message:

Recommended Tests

Generally, there's no single best command line for testing. Instead, using multiple command lines are necessary to create different I/O footprints and to utilize different API's (sync versus async, for example).

As mentioned above, variety is better than running the same fixed tests over and over. This includes varying the I/O sizes, the direction, and the I/O type, as well as using different data patterns. When doing file system testing with multiple passes (passes= or runtime= options), you may wish to truncate files between each pass via oflags=trunc to avoid overwriting blocks with the same data (although this is a non-issue when using IOT pattern, since pass is factored into the block seeding).

For direct (raw) disk I/O, there are several command lines to randomly select:
For file system testing, here are several command lines to randomly select:
  • dt of=${MountPoint} min=1 max=256k incr=var limit={FileSize} iodir={forward|reverse} iotype={random|sequential}
  • dt of=${MountPoint} min=d max=256k incr=var limit={FileSize} pattern=iot iodir={forward|reverse} iotype={random|sequential}
  • dt of=${MountPoint} min=5 max=256k incr=var limit={FileSize} enable=lbdata iodir={forward|reverse} iotype={random|sequential}
  • dt of=${MountPoint} bs=256k limit={FileSize} prefix="%d@%h"
  • For sequential I/O, randomly choose: iodir={reverse|forward}
  • For clustered file systems, adding prefix="%d@%h" is useful.
  • Note: min=5 is necessary to allow space for encoding the lba.

  • Mail Send mail to admin of this page: Robin.Miller@netapp.com Home To Robin's home page.

    Last Modified: September 26th, 2008