[lkml]   [1999]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: fsync on large files
In article <199902140429.XAA29350@dcl>,
tytso@MIT.EDU (Theodore Y. Ts'o) writes:

> What the patch does is keep an array of the last four blocks which were
> modified since the last fsync(). If there have been no more than four
> blocks modified, then the ext2 filesystem can do a "fast fsync", which
> just flushes those four (or fewer) blocks to disk, without having to
> walk all of the indirect blocks looking for modified blocks. This
> should be extremely effective for programs like syslog which are doing
> frequent fsync()'s with minimal amounts of data written between calls to
> fsync().

This is a very important patch, because fsync() is needed in some
transaction oriented databases (they have to call fsync() or fdatasync()
on the log frequently to commit operations). For some of them 4 blocks
could be not enough though, perhaps a more generic version of your
patch that handles more than 4 blocks could be found - like keeping
the dirty blocks per inode on a special list.


This is like TV. I don't like TV.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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