On Fri, 25 Oct 1996 12:44:07 -0500, Ray Van Tassle-CRV004
<Ray_Van_Tassle-CRV004@email.mot.com> said:
>> I've seen a similar problem also. Running strace showed that syslogd
>> was doing fsync() quite often. As the log files grow, fsync() takes
>> longer and longer to complete. I don't know whether to consider this
>> an inefficiency in the fsync() implementation or poor behavior on the
>> part of syslogd for calling fsync() so often... We avoid this problem
>> by keeping our log files trimmed (via chklogs).
> I'd vote for "inefficiency in the fsync() implementation". What it does is
> fsync the entire disk that the file is on.
No it doesn't! Linux's fsync() only falls back on doing a
whole-device sync if it is used on a file whose filesystem doesn't
provide its own specific fsync code. All of the normal Linux
filesystems do have fsync implemented (and have had since pre-1.0
kernels).
However, it is still going to be slow to fsync a large file. If
nothing else, as the file grows there is going to be a larger and
larger physical gap between the disk block storint the file's inode
and its tail. Since fsync() has to update both the inode and the data
at the tail after an append operation, every fsync() is incurring a
seek penalty which can only grow over time. That's a necessary result
of fsync()ing a large file, I'm afraid.
Cheers,
Stephen.