On 27 Oct 2012, Eric Sandeen stated: > On 10/27/12 4:29 PM, Nix wrote: >> (But, seriously, fsstress is a wonderful thing. And the kernel's test >> culture *is* improving, and I'm happy to see filesystem hackers in the >> front line.) > > I've been testing with a hacked up devicemapper target which creates > a "dirty" snapshot which requires a replay; saves the actual power > drop & restore cycle, and I could repro the journal_checksum bug > right off. I'm just not sure why a umount -l of an unused-but-mounted dirty filesystem followed immediately by a reboot() is triggering a journal replay at all. If the umount has started, it should complete before the reboot and mark the fs clean and !needs_recovery, no matter how much dirty data it has to write -- all my testing in virtualization does just that -- but it clearly isn't working that way on real hardware (or, if it is, something is vaping the controller's cache after the umount has finished, which is pretty disturbing: nothing but simultaneous failure of two or more drives or the battery should be able to vape that cache before it is flushed, certainly not anything as simple as a device disconnection / reboot). > XFS has an ioctl to make this easy in regression testing, and several > tests in xfstests do cover xfs journal recovery. We need > to add such a thing to ext4. Not being able to programatically > test recovery is a problem. True enough. You can rest assured that I will continue being a test load if necessary -- though for now I have removed journal_async_commit from my mount options, at least until this bug is fixed, because I don't like being a test load *that* much! -- NULL && (void) -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
