From owner-freebsd-arch@FreeBSD.ORG Wed Jan 6 18:27:50 2010 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15D9D1065694 for ; Wed, 6 Jan 2010 18:27:50 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.freebsd.org (Postfix) with ESMTP id A30998FC12 for ; Wed, 6 Jan 2010 18:27:49 +0000 (UTC) Received: from c122-106-170-81.carlnfd1.nsw.optusnet.com.au (c122-106-170-81.carlnfd1.nsw.optusnet.com.au [122.106.170.81]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o06IRf6k007831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Jan 2010 05:27:42 +1100 Date: Thu, 7 Jan 2010 05:27:41 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Oliver Fromme In-Reply-To: <201001061240.o06Ce74L050540@lurza.secnetix.de> Message-ID: <20100107045335.N55224@delplex.bde.org> References: <201001061240.o06Ce74L050540@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1763835519-1262802461=:55224" Cc: des@des.no, freebsd-arch@FreeBSD.org Subject: Re: File system blocks alignment X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2010 18:27:50 -0000 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--