Re: fsync(2) weirdness

Scott Laird (laird@pacificrim.net)
Fri, 03 Oct 1997 12:13:34 -0700


In message <Pine.LNX.3.95.971003101603.316A-100000@nextd.demon.co.uk>, Mark Hem
ment writes:
>
>Its even worse - there are _two_ passes made.....
>Perhaps I'm still living in the 80386 33MHz world, but for the number of
>look-ups made, 100s seems only a little excessive.
>
>> --- file.c-old Thu Oct 2 17:54:01 1997
>> +++ file.c Thu Oct 2 17:54:15 1997
>> @@ -54,7 +54,7 @@
>> generic_file_mmap, /* mmap */
>> NULL, /* no special open is needed */
>> ext2_release_file, /* release */
>> - ext2_sync_file, /* fsync */
>> + NULL, /* fsync */
>> NULL, /* fasync */
>> NULL, /* check_media_change */
>> NULL /* revalidate */
>
>Without fsync set, no sync is performed.
>
>Try changing "ext2_sync_file" to "file_sync".
>"file_sync" syncs all the dirty buffers on the file-system, and waits for
>completion of the sync.

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