[Fwd: faster fsync and real fdatasync [patch against 2.3.18]]

1999-10-09 Thread Martin Schenk
I noticed that sys_fsync can be very slow, because it has to scan all cached pages of the file (this takes about 1ms/MByte on my dual P3-450). I wrote a patch that fixes this problem and adds an implementation of fdatasync (the inode does not get flushed if only mtime/ctime are changed). I

[Fwd: some benchmark data for fsync (2.3.19, 2.3.19+fastsync, NT)]

1999-10-09 Thread Martin Schenk
Here are some benchmark data to show the difference my fastsync patch (posted here a few days ago as "faster fsync and real fdatasync") can make. Basically this patch omits a scan through all the cached blocks of a file on fsync and it enables fdatasync not to sync the inode if only

Re: [patch] [possible race in ext2] Re: how to write get_block?

1999-10-09 Thread Andrea Arcangeli
On Fri, 8 Oct 1999, Mikulas Patocka wrote: Here goes quick'n'dirty patch. It does bforget(). It should prevent file corruption. wrong patch. bforget give you no guarantee at all. bfoget always fallback to brelse if necessary. What I said about bforget in my old email is still true. The _only_

Re: [possible race in ext2] Re: how to write get_block?

1999-10-09 Thread Ingo Molnar
On Fri, 8 Oct 1999, Alexander Viro wrote: yep we knew about this problem ... it's not quite an easy hack though. Putting the directory block cache (and symlink block cache) into the page cache would be the preferred method - this would also clean up the code alot i think. More or