On Thu, Mar 1, 2018 at 11:25 AM, Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote: > > > On 2018年03月01日 16:39, Amir Goldstein wrote: >> On Thu, Mar 1, 2018 at 7:38 AM, Qu Wenruo <wqu@xxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
