1 2 . 5
T Y P E S O F T E S T S
209
The rename test is a simple shell script that creates a hierarchy of direc-
tories all initially named
aa
. In each directory another script is run that re-
names the subdirectory from
aa
all the way to
zz
and then back to
aa
. This
may seem like a trivial test, but in a system such as the BeOS that sends
notifications for updates such as renames, this test generated a lot of traffic.
In addition, when run in combination with the other tests, it also exposed
several race conditions in acquiring access to file system data structures.
The random I/O test was geared at exercising the
data stream
structure as
well as the rest of the I/O system. The motivation behind it was that most
programs perform simple sequential I/O of fixed block sizes, and thus not all
possible alignments and boundary cases receive adequate testing. The goal of
the random I/O test was to test how well the file system handled programs
that would seek to random locations in the file and then perform randomly
sized I/O at that position in the file. This tested situations such as reading
the last part of the last block in the indirect blocks of a file and then reading
a small amount of the first double-indirect block. To verify the correctness of
the reads, the file is written as a series of increasing integers whose value is
XORed with a seed value. This generates interesting data patterns (i.e., they
are easily identifiable) and it allows easy verification of any portion of data in
a file simply by knowing its offset and the seed value. This proved invaluable
to flushing out bugs in the
data stream
code that surfaced only when reading
chunks of data at file positions not on a block boundary with a length that
was not a multiple of the file system block size. To properly stress the file
system it was necessary to run the random I/O test after running the disk
fragmenter or in combination with the other tests.
Beyond the above set of tests, several smaller tests were written to examine
other corner conditions in the file system. Tests to create large file names,
hierarchies that exceed the maximum allowable path name length, and tests
that just kept adding attributes to a file until there was no more disk space
all helped stress the system in various ways to find its limitations. Tests that
ferret out corner conditions are necessary since, even though there may be a
well-defined file name length limitation (255 bytes in BFS), a subtle bug in
the system may prevent it from working.
Although it was not done with BFS, using file system traces to simulate
disk activity is another possibility for testing. Capturing the I/O event log
of an active system and then replaying the activity borders between a real-
world test and a synthetic test. Replaying the trace may not duplicate all the
factors that existed while generating the trace. For example, memory usage
may be different, which could affect what is cached and what isn't. Another
difficulty with file system traces is that although the disk activity is real, it
is only a single data point out of all possible orderings of a set of disk activity.
Using a wide variety of traces captured under different scenarios is important
if trace playback is used to test a file system.
Practical File System Design:The Be File System
, Dominic Giampaolo
page 209