Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 7 Jan 2010 05:27:41 +1100 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        Oliver Fromme <olli@lurza.secnetix.de>
Cc:        des@des.no, freebsd-arch@FreeBSD.org
Subject:   Re: File system blocks alignment
Message-ID:  <20100107045335.N55224@delplex.bde.org>
In-Reply-To: <201001061240.o06Ce74L050540@lurza.secnetix.de>
References:  <201001061240.o06Ce74L050540@lurza.secnetix.de>

next in thread | previous in thread | raw e-mail | index | archive | help
  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--0-1763835519-1262802461=:55224
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Wed, 6 Jan 2010, Oliver Fromme wrote:

> Dag-Erling Sm=F8rgrav wrote:
> > As for newfs, the defaults are fine as long as the filesystem doesn't
> > fill up to the point where UFS starts using fragments - but when it
> > does, you're in trouble anyway, so there's no point in overriding the
> > defaults unless it makes sense for your data: a filesystem used mostly
> > to store large files may benefit from increased block / fragment sizes,
> > but remember to keep the 8:1 ratio.
>
> I've created file systems with 1:1 ratio in the past
> for storing large files (multimedia stuff and similar),
> and with a very low inode density.  So far I haven't
> encountered any problems.
>
> Is there a reason for not using a 1:1 ratio, and
> should I rebuild my file systems with 1:8 ratio?

Few, and few.  No bugs are known, but 1:1 might be least efficient of
all possible ratios.

Using a ratio of other than 8:1 means that you don't trust ffs's
fragmentation or clustering code.  This is partly justified, but the
effects of changing the ratio are tiny (except reducing it to 8:8 gives
large inefficiencies if the block size is large) and very device-dependent.
In my tests on fresh copies of /usr/src, a fragment size of 4K is best
for all possible block sizes except 4K:4K (1:1 is generally slower)
and 64K:4K (not supported).  The best ratio was 8:1 for 32K:4K and the
next best was 4:1 for 16K:4K.  Only 64K:any and 32K:32K worked very
inefficiently.  (In theory, both 32K:any and 64K:any should work fairly
inefficiently, due to fragmentation of the buffer cache, but I have
only noticed this effect for 64K:any.)

I once tried using 4K:4K for /home/ncvs, on the theory that this should
reduce fragmentation, with filling in of fragments causing especially
bad effects.  (Aged ffs file systems normally have lots of external
fragmentation, so that reads of an aged /home/ncvs typically take 5-10
times as long as for a new one.)  This didn't work as expected -- the
file system became slow anyway, and filled up sooner since the 4K:4K
ratio is wasteful.

Bruce
--0-1763835519-1262802461=:55224--



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