Messages in this thread |  | | Date | Fri, 24 Jan 2003 22:53:20 -0800 | From | Andrew Morton <> | Subject | Re: ext2 FS corruption with 2.5.59. |
| |
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |