Re: [RFC PATCH] fstests: Check if a fs can survive random (emulated) power loss

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2019 bytes --]



On 2018年02月26日 16:15, Amir Goldstein wrote:
> On Mon, Feb 26, 2018 at 9:31 AM, Qu Wenruo <wqu@suse.com> wrote:
>> 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)


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

Thanks,
Qu

> 
> 2. Absolute guaranty to reproducing the problem by replaying the write log.
>     Even though your fsstress could use a pre-defined random seed to results
>     will be far from reproduciable, because of process and IO scheduling
>     differences between subsequent test runs.
>     When you catch an inconsistency with log-writes test, you can send the
>     write-log recording to the maintainer to analyze the problem, even if it is
>     a hard problem to hit. I used that useful technique for ext4,btrfs,xfs when
>     ran tests with generic/455 and found problems.
> 
> Cheers,
> Amir.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 520 bytes --]