lkml.org 
[lkml]   [1996]   [Nov]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: syslog spiral death
Hi,

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.


\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.062 / U:0.940 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site