From owner-freebsd-arch Mon Nov 26 7: 6:57 2001 Delivered-To: freebsd-arch@freebsd.org Received: from axl.seasidesoftware.co.za (axl.seasidesoftware.co.za [196.31.7.201]) by hub.freebsd.org (Postfix) with ESMTP id 9525037B405 for ; Mon, 26 Nov 2001 07:06:49 -0800 (PST) Received: from sheldonh (helo=axl.seasidesoftware.co.za) by axl.seasidesoftware.co.za with local-esmtp (Exim 3.33 #1) id 168NMP-00091C-00; Mon, 26 Nov 2001 17:07:53 +0200 From: Sheldon Hearn To: Matthew Dillon Cc: Kirk McKusick , freebsd-arch@FreeBSD.ORG Subject: Re: Using a larger block size on large filesystems In-reply-to: Your message of "Sat, 24 Nov 2001 10:45:22 PST." <200111241845.fAOIjM377587@apollo.backplane.com> Date: Mon, 26 Nov 2001 17:07:53 +0200 Message-ID: <34669.1006787273@axl.seasidesoftware.co.za> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 24 Nov 2001 10:45:22 PST, Matthew Dillon wrote: | The only thing I worry about is reduced performance when doing | random database accesses, which makes me kinda want to give the | system the capability to do smaller I/O's :-) Yes. My feeling is that there is sufficient breadth of access pattern in the spectrum of useful applications as to make a "one size fits all" default impossible to attain. I'm off the opinion that the set of useful applications installed on FreeBSD systems is weighted more toward MTA-like access on small files. This may just be because we don't seem to have an Oracle-class RDBMS available for FreeBSD. I'm guessing that the graph looks something like this: Installations ^ | ************ | ****** **** | ***** *** |**** ** | * | * +------------------------------------------| Access Pattern MTA-like access <-|-> RDBMS-like access We can either continue along the middle ground that does not offer optimal performance to anyone, or we can try to deliver optimal performance to the applications that weigh in heavier on the spectrum and require operators of other applications to be sensible about filesystem tuning. The status quo forces operators of high-performance applications at BOTH ends of the spectrum to engage in fs tuning. So I think it's worthwhile to to decide on the end of the spectrum that delivers optimal performance to the largest number of installations (NOT the largest number of available applications). Do you agree with me that we'd benefit the largest number of installations by targetting applications with MTA-like access on small files? Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message