File system tests

[Poul-Henning Kamp]

In message <20051116081917.GA56826 at peter.osted.lan>, Peter Holm writes:
>In an effort to test how well the kernel handles corrupted file
>systems (UFS2), I have run a series of test where I flip random
>bits in a file system, run fsck and then mount it. This has uncovered
>a few panics:
>
>panic: mount: lost mount
>panic: vm_fault: fault on nofault entry, addr: dda79000
>panic: getblk: size(536871936) > MAXBSIZE(65536)
>panic: wrong length 1088 for sectorsize 512
>panic: kmem_malloc(1342181376): kmem_map too small: 11620352 total allocated
>
>http://people.freebsd.org/~pho/stress/log/fs01.html
>http://people.freebsd.org/~pho/stress/log/fs02.html
>http://people.freebsd.org/~pho/stress/log/fs03.html
>http://people.freebsd.org/~pho/stress/log/fs04.html
>http://people.freebsd.org/~pho/stress/log/fs05.html
>
>I'm still not sure if this a reasonable test scenario and if it's
>worth pursuing?

Veritas VxFS does cope, it never trusts data on the disk until
validated and it will seletively declare an inode toast if it feels
that is necessary.

Over the last five years or so, I have changed my perception of on
disk data from being "private data" to being "communications protocol",
primarily because media flies in and out of machines these days, but
also because of dual-booting and virtualization etc.

So I would think that in these days and times, all filesystems be
robust against disk bits, but I also know our code well enough to
say that we are pretty far away indeed.

Summary: Highly recommended area to work in.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.