Danny Milosavljevic wrote:
Hi,
On Wed, 08 Nov 2006 03:21:36 -0700, Andreas Dilger wrote:
On Nov 08, 2006 10:15 +0100, Francesco Biscani wrote:
I think the slow performance you're experiencing are caused by the fsync()
call not being well-optimized in reiser4. I've commented out the function in
fs/buffer.c, and I'm having much better performance on my / partition.
I don't think this can be advocated as a real solution to performance
problems. This can mean data loss for some applications like email that
expect "fsync return" to mean "this data is safely on disk".
I've never understood this kind of attitude some MTAs have. Usually the
hardware would make sure that stuff doesn't disappear (UPS, powered RAM,
harddisk condenser) and not some weird software workaround that complicates
and slows down everything.
The only possibility one could still lose mail when having proper
hardware failsafes would be if the kernel had a bug and crashed (and that's
so bad, it doesn't really warrant any working around it).
Ever used DOS with smartdrv? smartdrv gave a performance boost by
storing recently touched files in memory and writing to disk later. This
is called a disk cache. You would be explicitly told to NOT just turn
off the computer each time smartdrv was loaded. You had to first clear
the cache and then you could power off the box otherwise you would lose
any data sitting in the cache that had not been flushed.
All current Unices have disk cache capabilities built-in and the only
way to bypass the disk cache for those applications that needed to have
their data definitely written to disk and not sitting the cache was the
fsync and fsyncdata calls.
