Hello, On Tue, Aug 18, 2015 at 10:47:18AM -0700, Tejun Heo wrote: > Hmm... the only possibility I can think of is tot_write_bandwidth > being zero when it shouldn't be. I've been staring at the code for a > while now but nothing rings a bell. Time for another debug patch, I > guess. So, I can now reproduce the bug (it takes a lot of trials but lowering the number of tested files helps quite a bit) and instrumented all the early exit paths w/o the fix patch. bdi_has_dirty_io() and wb_has_dirty_io() are never out of sync with the actual dirty / io lists even when the test 048 fails, so the bug at least is not caused by writeback skipping due to buggy bdi/wb_has_dirty_io() result. Whenever it skips, all the lists are actually empty (verified while holding list_lock). One suspicion I have is that this could be a subtle timing issue which is being exposed by the new short-cut path. Anything which adds delay seems to make the issue go away. Dave, does anything ring a bell? As for the proposed I_DIRTY_TIME fix, I think it'd be a good idea to merge it. It fixes a clear brekage regardless of this xfs issue. Thanks. -- tejun _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
