1 2 . 7
S U M M A R Y
213
after running three or four synthetic tests simultaneously for 16 hours or
more. The lesson is that simply bumping into a limit may not be adequate
testing. It may be necessary to ram head-on into the limit for days on end to
properly flush out all the possible bugs.
Before the first release of BFS, the system stabilized to the point where cor-
rupting a hard disk took significant effort and all the real-world tests would
run without corruption for 24 hours or more. At first customer ship, the file
system had one known problem that we were unable to pinpoint but that
would only happen in rare circumstances. By the second release (two months
later) several more bugs were fixed, and the third release (another two months
later) saw the file system able to withstand several days of serious abuse.
That is not to say that no bugs exist in the file system. Even now occasion-
ally an obscure bug appears, but at this point (approximately 16 months after
the initial development of the file system), bugs are not common and the
system is generally believed to be robust and stable. More importantly, cor-
rupted file systems have been thankfully rare; the bugs that surface are often
just debugging checks that halt the system when they detect data structure
inconsistencies (before writing them to disk).
12.7
Summary
The real lesson of this chapter is not the specific testing done in the devel-
opment of BFS, but rather that testing early and often is the surest way to
guarantee that a file system becomes robust. Throwing a file system into the
gaping jaws of a rabid test group is the only way to shake out the system.
Balancing the need to implement features with the need to have a stable base
is difficult. The development of BFS saw that iterating between features and
bug-fixing worked well. In the bug-fixing phase, rapid response to bugs and
good communication between the testing and development group ensures
that the system will mature quickly. Testing a wide variety of CPU, mem-
ory, and I/O configurations helps expose the system to as many I/O patterns
as possible.
Nothing can guarantee the correctness of a file system. The only way to
gain any confidence in a file system is to test it until it can survive the harsh-
est batterings afforded by the test environment. Perhaps the best indicator of
the quality of a file system is when the author(s) of the file system are willing
to store their own data on their file system and use it for day-to-day use.
Practical File System Design:The Be File System
, Dominic Giampaolo
page 213
Summary :
Even now occasion- ally an obscure bug appears, but at this point (approximately 16 months after the initial development of the file system), bugs are not common and the system is generally believed to be robust and stable. Perhaps the best indicator of the quality of a file system is when the author(s) of the file system are willing to store their own data on their file system and use it for day-to-day use.
Tags :
bugs,testing,release,bfs,only,months,but,deelopment,test,way,into,need,rare