It would be nice if SPEC SFS '97 could test non-NFS file systems.
For my testing of stackable file systems, I unpack, configure, and build
several large packages: am-utils, egcs-1.1.2, binutils, and emacs-20.4. I
run a loop of "configure;make; make clean" about 10-20 times. I watch for
any obvious bugs/oopses, odd kernel messages, creeping-up memory
utilization, and such. I also check for any leftover locked vnodes/inodes
or ones with incorrect reference counts; to detect some of that I try to
unmount and remount my file system, and also unmount and remount the
underlying file system. Any bad locks or refcounts will cause trouble when
you try to unmount, remount, or fsck.
I also use bonnie.
Over the past few years, I've written over two dozen small C programs
intended to test specific features. For example, a lot of the complexity in
my stackable f/s has to do with mmap'ed pages. So I have a program that
opens and mmaps files, then it reads/writes specific pages, page ranges, and
bytes just around page boundaries. I used that to detect and fix boundary
conditions.
I'm pretty sure that everyone who ever wrote a file system has written a few
test programs. My small test programs are intended for testing stackable
f/s. I'm sure developers of other f/s have written tests specific to their
f/s. Maybe the fsdevel community should join forces and put together a real
f/s regression tests package. That would be useful for every filesystem on
Unix systems, not just Linux. I'd be happy to contribute to such an effort
if one were organized.
Erez.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/