On 2018年02月26日 16:33, Amir Goldstein wrote:

On Mon, Feb 26, 2018 at 10:20 AM, Qu Wenruo [off-list ref] wrote:

quoted

On 2018年02月26日 16:15, Amir Goldstein wrote:

quoted

On Mon, Feb 26, 2018 at 9:31 AM, Qu Wenruo [off-list ref] wrote:

quoted

This test case is originally designed to expose unexpected corruption
for btrfs, where there are several reports about btrfs serious metadata
corruption after power loss.

The test case itself will trigger heavy fsstress for the fs, and use
dm-flakey to emulate power loss by dropping all later writes.

Come on... dm-flakey is so 2016
You should take Josef's fsstress+log-writes test and bring it to fstests:
https://github.com/josefbacik/log-writes

By doing that you will gain two very important features from the test:

1. Problems will be discovered much faster, because the test can run fsck
    after every single block write has been replayed instead of just at random
    times like in your test

That's what exactly I want!!!

Great thanks for this one! I would definitely look into this.
(Although the initial commit is even older than 2016)

Please note that Josef's replay-individual-faster.sh script runs fsck
every 1000 writes (i.e. --check 1000), so you can play with this argument
in your test. Can also run --fsck every --check fua or --check flush, which
may be more indicative of real world problems. not sure.

quoted

But the test itself could already expose something on EXT4, it still
makes some sense for ext4 developers as a verification test case.

Please take a look at generic/456
When generic/455 found a reproduciable problem in ext4,
I created a specific test without any randomness to pin point the
problem found (using dm-flakey).
If the problem you found is reproduciable, then it will be easy for you
to create a similar "bisected" test.

Yep, it's definitely needed for a pin-point test case, but I'm also
wondering if a random, stress test could also help.

Test case with plain fsstress is already super helpful to expose some
bugs, such stress test won't hurt.

Thanks,
Qu

Thanks,
Amir.