Re: ext2 FS corruption with 2.5.59.

[Andrew Morton <akpm@digeo.com>]

Oleg Drokin <green@namesys.com> wrote:
>
> Ok, So far simplest way of reproducing for me was this:
> mkdir /mnt
> fsstress -p 10 -n1000000 -d /mnt &
> fsx -c 1234 testfile
> 
> Now look at fsx output. When it says about "truncating to largest ever: 0x3ffff",
> wait 10 more seconds and if nothing happens, ^C the fsx,
> run "rm -rf testfile*"
> now run fsx again
> and so on until it fails.
> 
> Last time it took me three iterations to reproduce.
> 

Well I've been running this for a couple of hours:

	#!/bin/sh
	while true
	do
	        fsstress -p 10 -n1000000 -d . &
	        fsx-linux -c 1234 testfile &
	        sleep 180
	        killall fsx-linux fsstress
	        sleep 1
	done

Chance of close/open is 1 in 1234
seed = 1043574092
truncating to largest ever: 0x13e76
truncating to largest ever: 0x2e52c
truncating to largest ever: 0x3c2c2
truncating to largest ever: 0x3f15f
truncating to largest ever: 0x3fcb9
truncating to largest ever: 0x3fe96
truncating to largest ever: 0x3ff9d
truncating to largest ever: 0x3ffff
skipping zero size read
skipping zero size write
/home/akpm/fsx-test: line 9:  1253 Terminated              fsstress -p 10 -n1000000 -d .
signal 15
testcalls = 95103
seed = 1043594552


So I'm going to have to ask you to investigate further.  Does it happen on
other machines?  Other filesystems?  Older kernels?  That sort of thing.

Thanks.