Date: Tue, 23 Sep 1997 04:20:00 -0500 (EST) From: "John S. Dyson" <toor@dyson.iquest.net> To: syssgm@dtir.qld.gov.au (Stephen McKay) Cc: freebsd-current@FreeBSD.ORG, syssgm@dtir.qld.gov.au Subject: Re: New timeout capability (was Re: cvs commit:....) Message-ID: <199709230920.EAA00190@dyson.iquest.net> In-Reply-To: <199709230818.SAA07263@troll.dtir.qld.gov.au> from Stephen McKay at "Sep 23, 97 06:18:58 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Stephen McKay said: > >> > >32K or even 64K should work :-). With our upcoming dynamic buffer size > >allocation, we could even do 256K? :-). > > Gods! What for? (Ok, that's just an initial exclamation.) > > My curiosity about the 4Kb vs 8Kb derives from the good job the clustering > code does. If we have good clustering, then why have big block sizes? They > just move the breakpoints for max file size before indirect blocks are > needed (and similarly the max file size that can have fragments). > Actually, it is mostly a matter of minimizing the amount of accounting the system does building up the "big buffers" on the fly with clustering. Actually, I was very much jesting :-). I could possibly imagine a reasonable use for a 16K basic allocation size. I think that 4K performs pretty darned well anyway though. In the real world, I wouldn't think that one would see much of a performance difference between 4K and 16K. I am sure that iozone will measure a few percent better performance though. 256K is borderline silly, but would be interesting to try just once. It would waste one hell of a lot of space on most often U**X filesystem distributions. Now, all this said, it will be helpful to support 256K or bigger clusters, esp on writes. But, the userland visible block size shouldn't often have to be bigger than 4-16K. -- John dyson@freebsd.org jdyson@nc.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709230920.EAA00190>