* Dave Chinner: > On Thu, Dec 10, 2009 at 09:22:35AM +0000, Florian Weimer wrote: >> I've got an odd performance issue. It seems that when fsync() is >> called on a file, other processes block when they try to access it. >> This is not merely due to I/O contention on the underlying block >> device, it seems. > > The inode mutex is held across the ->fsync() method. If that takes a > long time to run, then other processes will block trying to take the > inode mutex. i.e. part of fsync serialises access to the inode. Is an inode lock required to read from the file? >> Oracle reported a similar performance issue in the Berkeley DB JE >> changelog. Is this really true? Are there any workarounds? (I'm >> mainly interested in the situation on ext[34] and XFS.) > > For XFS, the ->fsync method blocks for as long as it takes to write > a synchronous transaction (1 IO). ext4 looks like it writes the > inode rather than doing a journal commit, so it should only need a > single IO with the inode mutex held, too. I don't think these can be > optimised any further. 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. -- 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
