* 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 [307396.186071] Call Trace: [307396.186128] [<ffffffff8042963d>] __mutex_lock_slowpath+0x64/0x9b [307396.186160] [<ffffffff804294a2>] mutex_lock+0xa/0xb [307396.186190] [<ffffffff8029b749>] generic_file_llseek+0x2a/0x8b [307396.186219] [<ffffffff8029b8f8>] sys_lseek+0x40/0x60 [307396.186248] [<ffffffff8020beca>] system_call_after_swapgs+0x8a/0x8f -- Florian Weimer <fweimer@xxxxxx> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 -- 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
