Messages in this thread |  | | Date | Sat, 22 Sep 2001 21:32:18 +0200 | From | Matthias Andree <> | Subject | Re: [PATCH] Significant performace improvements on reiserfs systems, kupdated bugfixes |
| |
On Sun, 23 Sep 2001, Beau Kuiper wrote:
> > Be careful! MTAs rely on this behaviour on fsync(). The official > > consensus on ReiserFS and ext3 on current Linux 2.4.x kernels (x >= 9) > > is that "any synchronous operation flushes all pending operations", and > > if that is changed, you MUST make sure that the changed ReiserFS/ext3fs > > still make all the guarantees that softupdated BSD file systems make, > > lest you want people to run their mail queues off "sync" disks. > > This code change does not affect the functionality of fsync(), only > kupdated. kupdated is responsible for flushing buffers that have been > sitting around too long to disk.
Sorry, I didn't grok that when writing my previous mail in this thread. I thought kupdate was the one that writes ReiserFS transactions, but that's kreiserfsd, I think.
> > Note also, if these blocks belong to newly-opened files, you definitely > > want kupdated to flush these to disk on its next run so that the files > > are still there after a crash. > > They still are (they would be flushed out by the sync_inodes call in > sync_old_buffers. But why are the file records for any new file more > important than changes to old files? (This is what an application can > determince, the kernel should just do what the app says, and treat > everything else fairly)
Not really, but open is a directory operation, while writing is a file operation. Directory operations have been flushed earlier traditionally (5s vs. 30s).
-- Matthias Andree
"Those who give up essential liberties for temporary safety deserve neither liberty nor safety." - Benjamin Franklin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |