From owner-freebsd-current Tue Sep 23 02:20:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA01252 for current-outgoing; Tue, 23 Sep 1997 02:20:12 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA01247 for ; Tue, 23 Sep 1997 02:20:08 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id EAA00190; Tue, 23 Sep 1997 04:20:00 -0500 (EST) From: "John S. Dyson" Message-Id: <199709230920.EAA00190@dyson.iquest.net> Subject: Re: New timeout capability (was Re: cvs commit:....) In-Reply-To: <199709230818.SAA07263@troll.dtir.qld.gov.au> from Stephen McKay at "Sep 23, 97 06:18:58 pm" To: syssgm@dtir.qld.gov.au (Stephen McKay) Date: Tue, 23 Sep 1997 04:20:00 -0500 (EST) Cc: freebsd-current@FreeBSD.ORG, syssgm@dtir.qld.gov.au Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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