> I know Ted T'so has/had a suite of tests he ran on ext2 before
> releasing any substantive changes.
Are these available somewhere for the writers of other filesystems?
I'd really like to give the affs some good testing before I'm
going to release the next patch. But a good test isn't easier to
write than the code to be tested.
To clarify --- my test suite is for e2fsck, and is included in the
e2fsprogs distribution. It does not test the actual kernel
implementation of the filesystems, itself.
I agree that a good test suite for testing generic filesystem
implementation is sorely needed. Anyone looking for a good project
which doesn't require much in the way of kernel internals? It would be
great way to get someone who's interested in getting more deeply
involved with the kernel started....
I can point out two good starting points. First, check out the NIST
Posix Test Compliance Suite (PCTS) for those sections which are related
to the filesystem --- this is a good place to check for correctness,
although some of the more exotic filesystems simply aren't POSIX
compliant, and there won't be much that can be done about that.
The other place to look as a starting point would be filesystem
benchmarks, since they tend to try to stress the filesystem.
Other than that, it simply requires someone with an evil mind, to test
out certain cases and make sure nothing unusual happens (where something
unusual can either be an unexpected result, or a kernel panic :-). For
example, what happens if you have one process which is writing to a file
as quickly as possible, and you have another process which is calling
the ftruncate() function as quickly as possible?
What happens if you have one process which is very quickly, in a loop,
creating and removing directories (and if the remove directory fails
because there are files in the directories, delete all of the files the
directory, and then retry the rmdir). Then in another process, try
creating files in that directory as quickly as possible.
The idea is to see if the filesystems have any nasty race conditions
which the test suite can exploit. As always, creating test cases is
best done by someone gets their jollies out of trying to break things. <grin>
- Ted