On Thu, Oct 06, 2016 at 03:24:52PM -0400, Theodore Ts'o wrote: > On Thu, Oct 06, 2016 at 08:29:28AM -0400, Brian Foster wrote: > > Doesn't necessarily bother me one way or the other, but something we've > > done with XFS in such situations is introduce a DEBUG mode only sysfs > > tunable that delays certain infrastructure (log recovery in our case) to > > coordinate with test cases that try to reproduce such timing/racing > > problems. > > The other approach the btrfs folks might consider is to have a > sufficiently powerful "debugfs" or "xfs_db" program that can generate > test images with the desired property. We can generate certain classes of testing images, eg. by mkfs, adding files and then corrupting specific keys after unmount. This could be unreliable for timing-dependent bugs, or catching some intermediate filesystem state that is created by kernel for free but would be tedious to recreate manually from scratch in userspace. > I've found that the time I've invested in creating debugfs has repaid > itself a hundred times over, especially when maintaining a regression > test suite for e2fsck. I agree that's a good thing. -- 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
