lkml.org 
[lkml]   [1997]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: fsync(2) weirdness
From
Date

In message <199710030050.UAA00411@gringo.telsur.cl>, Gordon Oliver writes:
>
>The problem would appear to be a combination of file size and sync behaviour
>(assuming that this is ext2). On any file, ext2 makes precisely two passes
>over the _entire_ file looking for buffers that are out of sync, and sync'ing
>them. In this case, if the file is ~1.4 G long, it will have to look up every
>buffer in the file, and then check those present to see if they are up to date
>Unfortunately, if most of them are not in the system, the search time is
>worse...

How hard would it be to do something like this inside ext2_sync_file?

if(big_file) {
scan the buffer cache and flush the ones for this inode (fsync_dev?);
} else {
continue as before;
}

Define big_file something like

(number of blocks in file > number of blocks in kernel buffers)


Would this work? I'm not all that familiar with kernel internals at
this level, but it seems like it would speed up fsync(2) on large
files.


Scott

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