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

Andreas Gruenbacher
2015-12-22T22:12:28Z

On Tue, Dec 22, 2015 at 10:48 PM, Eric Sandeen <sandeen@sandeen.net> wrote:
> 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?

The -S and -D options help narrow down problems somewhat (xfstests
always seems to use a constant seed value), but they don't allow
removing unrelated operations in between or changing the order of
operations. The .fsxops file makes that very easy; I've successfully
used it on a gfs2 bug.

Thanks,
Andreas