Messages in this thread | | | From | Peter Chubb <> | Date | Wed, 6 Nov 2002 10:09:42 +1100 | Subject | Re: [BK][PATCH] Reiser4, will double Linux FS performance, pleaseapply |
| |
>>>>> "Andreas" == Andreas Dilger <adilger@clusterfs.com> writes:
Andreas> I think the bdflush defaults are (were?) something like 5 Andreas> seconds for metadata, and 30 seconds for file data. reiser4 Andreas> should (if it doesn't already) use the parameters set by Andreas> sys_bdflush() to tune the writeout intervals.
...
Andreas> So, except for the very unusual case of files with lifespans Andreas> between 30 seconds and 300 seconds, or files that are written Andreas> to between those intervals, I would guess that you are not Andreas> gaining much extra benefit by deferring the writes another Andreas> 270 seconds.
Some benchmarking done at Berkeley showed that for development loads, 30seconds was too short to avoid excessive writes.
See Roselli, Lorch and Anderson, `A Comparison of File System Workloads' in Usenix 2000.
http://research.microsoft.com/~lorch/papers/fs-workloads/fs-workloads.html
Their observations (summarised) were that most blocks die because of overwriting, not because of file deletes. Their workloads show that for NT, the write timeout to avoid commits blocks that will soon become dead needs to be around a day; for typical Unix loads (web serving, research, software development), an hour is enough. To catch 75%, a timeout of around 11 minutes is needed. 30seconds worked only for webserving and undergraduate teaching workloads, and caught around 40% for those workloads; for a research workload and NT fileserving, 30seconds catches only 10-20% of the rewrites.
See especially figure 3 in that paper.
-- Dr Peter Chubb peterc@gelato.unsw.edu.au You are lost in a maze of BitKeeper repositories, all almost the same. - 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/
| |