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

Amir Goldstein amir73il at gmail.com
Thu Mar 1 11:15:24 UTC 2018


On Thu, Mar 1, 2018 at 11:25 AM, Qu Wenruo <quwenruo.btrfs at gmx.com> wrote:
>
>
> On 2018年03月01日 16:39, Amir Goldstein wrote:
>> On Thu, Mar 1, 2018 at 7:38 AM, Qu Wenruo <wqu at 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.
>>
>> So you are re-posting the test with dm-flakey or converting it to
>> dm-log-writes??
>
> Working on the scripts to allow us to do --find and then replay.
>
> Since for xfs and ext4, their fsck would report false alerts just for
> dirty journal.
>
> I'm adding new macro to locate next flush and replay to it, then mount
> it RW before we call fsck.
>
> Or do we have options for those fscks to skip dirty journal?
>

No, you are much better off doing mount/umount before fsck.
Even though e2fsck can replay a journal, it does that much slower
then the kernel does.

But why do you need to teach --find to find next flush?
You could use a helper script to run every fua with --fsck --check fua.
Granted, for fstests context, I agree that --find next fua may look
nicer, so I have no objection to this implementation.

Thanks,
Amir.




More information about the dm-devel mailing list