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. > 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. You can use an external log with XFS on separate spindles to the data volume to minimise the transaction latency, but that's about it AFAIK. For ext3, ordered mode can result in long (multi-second) fsync latencies on busy filesystems because of the journal commit involved. Using writeback mode will avoid the long latencies and make it operate close to ext4/XFS speeds. 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
