Re: [PATCH 6/6] fsx: Add mechanism to replay failed operations

Eric Sandeen
2015-12-22T21:48:43Z

On 12/22/15 2:53 PM, Andreas Gruenbacher wrote:
> Create a $name.fsxops file next to $test.fsxlog. When a test fails,
> dump the operations in the log into that file in a simple, parseable
> format like:
>
> fallocate 0x2e0f2 0xf04a 0x0 keep_size
> truncate 0x0 0x11e00 0x0 *
> write 0x73400 0x6c00 0x11e00
> skip punch_hole 0x71539913 0xdf76 0x7a000 close_open
> mapread 0x56000 0x16d08 0x7a000
>
> Here, each operation is on a separate line. When the first word is
> "skip", the operation will be skipped. The next parameters are offset,
> length, and the current file size, followed by optional flags like
> keep_size and clode_open. A trailing asterisk indicates that the
> operation overlaps with the operation that has failed.
>
> Add a --replay-ops option that allows to replay the operations recorded
> in such a $name.fsxops file. (The log can be modified to easily narrow
> down which operations are causing the failure.)

fsx already accepts a seed parameter; with the seed can't we simply replay
the operations by specifying the same seed with -S? And for narrowing down,
there's -D startingop and -N numops; doesn't that suffice?

And we already get an fsxlog like:

skipping zero size read
skipping insert range behind EOF
3 mapwrite 0x2e836 thru 0x3cba1 (0xe36c bytes)
4 insert from 0x12000 to 0x15000, (0x3000 bytes)
5 punch from 0xfb60 to 0x16c20, (0x70c0 bytes)
6 falloc from 0x31645 to 0x38d1d (0x76d8 bytes)
7 punch from 0x207c8 to 0x2224e, (0x1a86 bytes)
8 mapwrite 0xbcf1 thru 0x171ab (0xb4bb bytes)
9 collapse from 0x8000 to 0x13000, (0xb000 bytes)
...

from i.e. generic/075, but the cleanup function:

_cleanup()
{
cd /
rm -rf $TEST_DIR/fsx.* $tmp.*
}

removes it (even on a failure, I think, but I'm not certain).

Can't we just leverage what fsx already provides? I'm not sure what this
patch adds on top of that, am I missing something?

Thanks,
-Eric