On Fri, Dec 11, 2009 at 12:53:11PM +0000, Florian Weimer wrote: > * Dave Chinner: > > >> I'm not concerned with fsync latency per se. It's going to take a > >> while to write a few GBs scattered across the file. However, it's > >> annoying that read operations on the same file (which can't even see > >> the effect of the fsync operation) are blocked, some times for more > >> than two minutes. > > > > If they are blocking for that long then sysrq-w during that period > > will tell us exactly where in what filesystem they are blocking on.... > > Interesting. Is it possible to trigger this from the hang timer? > From that, I've got two traces: > > [307370.450502] Call Trace: > [307370.450555] [<ffffffff802aa9c8>] dput+0x1c/0xdd > [307370.450590] [<ffffffff8042a2e9>] __down_read+0x87/0xa1 > [307370.450641] [<ffffffffa0276cd8>] :xfs:xfs_ilock+0x31/0x60 > [307370.450684] [<ffffffffa029a208>] :xfs:xfs_read+0x147/0x21a > [307370.450718] [<ffffffff8029ae23>] do_sync_read+0xc9/0x10c > [307370.450750] [<ffffffff80246201>] autoremove_wake_function+0x0/0x2e > [307370.450787] [<ffffffff8029b614>] vfs_read+0xaa/0x152 > [307370.450815] [<ffffffff8029b9f5>] sys_read+0x45/0x6e > [307370.450844] [<ffffffff8020beca>] system_call_after_swapgs+0x8a/0x8f That is xfs_ilock(inode, XFS_IOLOCK_SHARED), which means it is blocked on a either a concurrent write, truncate or preallocation occurring to the same file. ->fsync does not take the IOLOCK at all (it takes the ILOCK which protects non-IO related inode attributes), so that is not causing your pauses here.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
