Messages in this thread | | | Date | Tue, 05 Nov 2002 13:39:07 -0800 | From | reiser <> | Subject | Re: [BK][PATCH] Reiser4, will double Linux FS performance, pleaseapply |
| |
Drew Roselli did traces of overwrite patterns, and the typical time to overwrite was about 6 minutes, so if you want the write cache to be effective you want it to last for more than 6 minutes. I encourage you to read the PhD thesis she wrote and argue with it and me on it, I am far from dogmatically certain that 10 minutes is the right amount of time. 60 seconds is the most I would want for my Dell laptop (laptops are crash prone). 10 minutes for a non-mobile computer with a UPS, or in an area with a competent electric utility company, is quite reasonable though. 10 minutes is clearly the right amount of time for, say, a user space programmer, and probably too risky for a kernel programmer. Probably kernel programmers are outnumbered 10 to 1 by user space programmers? ( I don't really know.)
There simply is not enough empirical data for what we argue about, unfortunately. Drew Roselli's thesis is the only one, and there is a need for 5 such theses before one can consider the topic reasonably understandable by the discerning. I worry a lot that her samples are distorted by site specific usage patterns that might not resemble those of the usual linux user.
I wish I personally had a better understanding of what the usual linux user does in the way of IO.....
Hans
Andreas Dilger wrote:
>On Nov 04, 2002 23:30 -0800, reiser wrote: > > >>The appropriate setting of >>transaction max age depends on the user. The setting we chose is >>appropriate for software developers doing compiles. It is not clear to >>me yet what the right setting is. Perhaps 3 minutes is more >>appropriate. I was probably overly influenced by Drew Roselli's >>statistics on how long the cyle is between rewrites. Her statistics are >>probably skewed by having lots of CS students using the machines she got >>her data from. 5 seconds is too short to perform good layout >>optimization for subsequent reads. >> >> > >I think the bdflush defaults are (were?) something like 5 seconds for >metadata, and 30 seconds for file data. reiser4 should (if it doesn't >already) use the parameters set by sys_bdflush() to tune the writeout >intervals. > >I would think that either: >a) A file was completely written in under 30 seconds (e.g. untar or gcc > or whatever else you are doing), so deferring allocation and writing > to disk does not help you at all. >b) A file is continuing to be written for more than 30 seconds that > has a very large amount of outstanding data which can be committed > to disk with (probably) the same read optimization quality as any > larger amount of data. >c) A file is continuing to be written for more than 30 seconds that > is growing slowly and no matter how long you defer the write you > will only get an incremental read layout. Presumably you could do > something to pre-allocate/reserve a bunch of space at the end of this > file as it continues to grow. > >So, except for the very unusual case of files with lifespans between 30 >seconds and 300 seconds, or files that are written to between those >intervals, I would guess that you are not gaining much extra benefit by >deferring the writes another 270 seconds. >
> >Cheers, Andreas >-- >Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, > \ would they cancel out, leaving him still hungry?" >http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert > > > >
- 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/
| |