Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 26 Nov 2001 17:07:53 +0200
From:      Sheldon Hearn <sheldonh@starjuice.net>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        Kirk McKusick <mckusick@beastie.mckusick.com>, freebsd-arch@FreeBSD.ORG
Subject:   Re: Using a larger block size on large filesystems 
Message-ID:  <34669.1006787273@axl.seasidesoftware.co.za>
In-Reply-To: Your message of "Sat, 24 Nov 2001 10:45:22 PST." <200111241845.fAOIjM377587@apollo.backplane.com> 

next in thread | previous in thread | raw e-mail | index | archive | help


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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?34669.1006787273>