lkml.org 
[lkml]   [1997]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: More on 2.1.65 slowdown (disc thrashing)
On Fri, 21 Nov 1997, Janos Farkas wrote:

> Just recently, fsync has been changed to unconditionally call sync(),
> because it has been found that fsync on very large files can take
> enormous times (even hours!). This is because it wanted to sync all
> the indirect blocks in addition to the changed data blocks, so it
> could be unbearably slow.

Unacceptable when a device sync is faster :)

> Now, it seems making this to sync() always
> is not too wise either. Possibly the best thing would be to do
> this only on substantially large files (>64M or so). Maybe making
> fdatasync() work in the same shot would be nice too, before the VFS
> interface will be frozen...

Well, we could just fsync all files with:
- only direct and single indirect blocks
- files that only have <= xx dirty blocks in-core

And files with double / triple indirect blocks can be
dev-synced (maybe even an 'asynchronous sync'... :-)

Rik.

----------
Send Linux memory-management wishes to me: I'm currently looking
for something to hack...


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