On Thu, Jun 24, 2004 at 01:04:56AM +0200, Gabriel Wicke wrote:
> I've posted my simplistic benchmark results at 
> http://coda.wikidev.net/Small_file_performance.
> Write-back caching was disabled as calling 'cfs wbstart <dir>' reliably
> freezes venus. Disk i/o was extremely high during creation/deletion of
> 1000 very small files, not sure if this is related to using xfs rather
> than ext2.
> 
> Are there ideas or plans on how to improve write performance? Jan
> indicated in an earlier post [1] that the main reason is the synchronous
> operation with fsync and possibly tcp handling.
> 
> I'm trying to install OpenAFS as well to do the same benchmark, its
> support for 2.6 is a bit lacking though. 
> 
> 1.) http://www.coda.cs.cmu.edu/maillists/codalist/codalist-2003/5021.html
> -- 

The following from [1] above struck me as quite funny for a filesystem
supporting disconnected operation..

"Coda works a lot like a (classic) BSD FFS filesystem, i.e. all metadata
updates are synchronous. Every single create, chmod, or chown won't
'complete' until the server is absolutely positive that the update has
hit the disk. "


So, my take is the case to optimize for is write-disconnected
operation.. Why can't we log all metadata updates? In linux's case, if
we run ext3 (or some other journaling filesystem) with metadata AND data
journalling, won't it be faster? Honestly, my take is once updates have
hit the RAM in venus, you can return to the application.

Also, as an excercise in .. well.. stupidity, how badly would things
break if I just got rid of all the fsync's? ;)

So, on another note.. would per-directory permits work better than
per-volume ones? Is this even feasable to implement?