You mean file_fsync?
I just rebooted with 2.0.31pre10 with ext2 using file_fsync instead of
ext2_sync_file. With 2.1.55, fsync on the 1.4GB database file
*averaged* 68 seconds. With the patch, fsyncs now average 0.12
seconds.
That's a pretty big win.
Here'a an (untested) hack to 2.0.31pre10's ext2_sync_file that reverts
to file_fsync if the file is large. It's a bad hack, but it's better
then *always* forcing fsync to perform a full sync, and it should be a
big performance boost for large databases. Could someone with a
better understanding of kernel internals try to fix this the *right*
way for 2.1.x?
--- fsync.c-orig Fri Oct 3 11:58:48 1997
+++ linux/fs/ext2/fsync.c Fri Oct 3 12:03:15 1997
@@ -176,6 +176,13 @@
*/
goto skip;
+ /* fsync on large files is *slow*, so fall back to sync() if
+ * the file's over 10M */
+ if (inode->i_size>10000000) {
+ file_fsync(inode,file);
+ goto skip;
+ }
+
for (wait=0; wait<=1; wait++)
{
err |= sync_direct (inode, wait);
Scott