On Wed, Nov 29, 2017 at 01:58:53PM -0600, Ashlie Martinez wrote:
> Ted,
>
> 1. write 0x137dd 0xdc69 0x0
> 2. fallocate 0xb531 0xb5ad 0x21446
> 3. collapse_range 0x1c000 0x4000 0x21446
> 4. write 0x3e5ec 0x1a14 0x21446
> 5. zero_range 0x20fac 0x6d9c 0x40000 keep_size
>
> I have made a CrashMonkey test that runs the same operations run by
> xfstests generic/456 as I wanted a bit more control over the test. My
> test runs operations 1-3 from the list above, and then runs sleep(30).
> After that, it runs operations 4 and 5 (I skipped operation 6 as it
> doesn't seem to be related to the underlying cause of the bug).
> CrashMonkey then waits a further 120 seconds for IO to trickle down to
> the block device.
So I'm not sure exactly what Crashmonkey is doing here. Are you
forcing a crash, or not?
So here's my test which I think should replicate what you are doing.
1. Start "kvm-xfstests shell"
2. Create the fsxops file:
cat > /tmp/fsxops
write 0x137dd 0xdc69 0x0
fallocate 0xb531 0xb5ad 0x21446
collapse_range 0x1c000 0x4000 0x21446
write 0x3e5ec 0x1a14 0x21446
zero_range 0x20fac 0x6d9c 0x40000 keep_size
<type control-d>
3. Create a scratch file system and mount it:
mke2fs -Fq -t ext4 /dev/vdc
mount /vdc
4. Run fsx:
./xfstests/ltp/fsx -d --replay-ops /tmp/fsxops /vdc/testfile
5. Since I'm too lazy to wait 120 seconds, just force everything to disk:
sync
6a. Unmount the file system and check it:
umount /vdc
e2fsck -fy /dev/vdc
6b. Force a crash, and then restart kvm-xfstests shell, and then check the file system:
<type control-A followed by 'x'>
kvm-xfstests shell
e2fsck -fy /dev/vdc
In both cases, e2fsck does not complain. In the 6b variant, e2fsck
will replay the journal first, but other than that, no real differences.
So, tell me --- how is what I am doing any different from your Crashmonkey test?
- Ted
