On Fri, Nov 21, 2014 at 05:00:31PM -0500, Josef Bacik wrote: > Hello, > > I'm hoping some FS guys can weigh in and verify my approach for testing power > fail conditions, and the DM guys to of course verify I didn't completely fail at > making a DM target. All suggestions welcome, I want to have a nice robust tool > for testing power fail so we can be sure our fsync/commit code is all working > properly. Thanks, *All* suggestions welcome? OK, I'll put on my skeptic hat. This implements a writeback cache in kernel data structures so that you can race to throw away cached blocks that haven't been flushed. How is that meaningfully different than using an actual writeback caching dm target and racing to invalidate it? Using real caching dm target configurations would let you reuse their testing and corner case handling that is, presumably, already slightly more advanced than printk() swearing. Implementation of this specific mechanism aside, the architectural observation is that device ram disappearing during a power interruption is just one, and possibly the most forgiving, outcome. Pulling the power out from under concurrnet cached writes can result in any combination of them being written, or not, or scrambled to the point of returning read errors. If we were to justify developing a specific power failure target, I'd like to see something that tracks write history and can replay the history to offer a resonably exhaustive set of possible write results. Verify *those* and you have much more confidence that the file system can handle reading the results of its interrupted writes. - z -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
