lkml.org 
[lkml]   [2001]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectWhy O_SYNC and fsync are slow in Linux?
Date
(Please CC your replies to me because I am not on the list.)

Hi!

Does anyone happen to know who is responsible for the file cache and
disk management in Linux?

On different systems I have measured strange differences in
performance depending on whether I open a file with O_SYNC and
let the operating system do the flushing of the file to disk
after each write, or if I open without O_SYNC, and call
fsync myself.

Some observations:

On Red Hat 6.2 and 7.? Intel big block writes are very slow if
I open the file with O_SYNC. I call pwrite to write 1 MB chunks to
the file, and I get only 1 MB/s write speed. If I open without O_SYNC
and call fsync only after writing the whole 100 MB file,
I get 5 MB/s. I got the same adequate speed 5 MB/s with 16 MB writes
after which I called fdatasync.

On a Linux-Compaq Alpha I measured the following: if I open with O_SYNC,
I can flush the end of my file (it is a log file) to
disk 170 times / second. If I do not open with O_SYNC,
but call fsync or fdatasync after each write, I get only 50
writes/second.

On the Red Hat 7.? I get 500 writes per second if I open with O_SYNC.
That is too much because the disk does not rotate
500 rotations/second. Does the disk fool the operating
system to believe a write has ended while it has not?

On Windows NT I have not noticed such performance problems if
I use non-buffered i/o to a file.

I have written a database engine InnoDB under MySQL and bumped into
these problems on Linux.

Regards,

Heikki Tuuri
Innobase Oy
http://www.innobase.fi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:53    [W:0.031 / U:9.436 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site