From owner-freebsd-fs@FreeBSD.ORG Tue Dec 13 09:15:09 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D3E21065672 for ; Tue, 13 Dec 2011 09:15:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 057A68FC17 for ; Tue, 13 Dec 2011 09:15:08 +0000 (UTC) Received: from alf.home (alf.kiev.zoral.com.ua [10.1.1.177]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id pBD9Ewnh076089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Dec 2011 11:14:58 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from alf.home (kostik@localhost [127.0.0.1]) by alf.home (8.14.5/8.14.5) with ESMTP id pBD9Evt9038621; Tue, 13 Dec 2011 11:14:57 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by alf.home (8.14.5/8.14.5/Submit) id pBD9EvLw038620; Tue, 13 Dec 2011 11:14:57 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: alf.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 13 Dec 2011 11:14:57 +0200 From: Kostik Belousov To: Dieter BSD Message-ID: <20111213091457.GU50300@deviant.kiev.zoral.com.ua> References: <20111212235034.218250@gmx.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MzUVogtTSRhL5bvu" Content-Disposition: inline In-Reply-To: <20111212235034.218250@gmx.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org, freebsd-performance@freebsd.org Subject: Re: Maximum blocksize for FFS? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 09:15:09 -0000 --MzUVogtTSRhL5bvu Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 12, 2011 at 06:50:33PM -0500, Dieter BSD wrote: > Many recent disks have a 4KiB sector size, so newfs's default > 2KiB frag size seems suboptimal for these drives. Newfs's man > page states: "The optimal block:fragment ratio is 8:1. Other > ratios are possible, but are not recommended, and may produce > poor results." =9A(It is not clear to me what the 8:1 ratio optimizes, > or exactly what poor results one should expect with a different ratio?) > Thus one would logically think of using 32 KiB blocksize 4KiB fragsize > at a minimum with these drives. >=20 > But, from a discussion in 2009: >=20 > Bruce Evans wrote: > > Any block size above the default (16K) tends to thrash and fragment buf= fer > > cache virtual memory. =9AThis is obviously a good pessimization with lo= ts of > > small files, and apparently, as you have found, it is a good pessimizat= ion > > with a few large files too. =9AI think severe fragmentation can easily = take > > several seconds to recover from. =9AThe worst case for causing fragment= aion > > is probably a mixture of small and large files. >=20 > This caused a *severe* performance problem and I was forced to reduce to > reduce my blocksize to 16KiB. =9A:-( >=20 > For data filesystems with large files (multi GB), there are many advantag= es > to using large blocksizes such as less space wasted on bookkeeping, > and faster fsck times. >=20 > So I'm wondering if this buffer cache virtual memory thrashing/fragmenting > problem has been fixed? =9AIs it safe to use 64KiB/8KiB yet? =9AIIRC I've > read concerns about thrashing/fragmenting due to different filesystems > having different sizes, say one filesystem being 16K/2K and another being > 64k/8K? >=20 > Also, has the "bug in vfs_bio.c" been fixed? (64KiB blocksize can > hang the system) >=20 > Any other gottchas? I think the default KVA allocated for the buffer cache might be too small for the 64KB blocks. The only known issue that prevented defragmentation from working was fixed in r189878. I did not see further reports of the hangs caused by fragmented buffer KVA. --MzUVogtTSRhL5bvu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk7nF5EACgkQC3+MBN1Mb4gXLQCfc5Avzx04azOdEpi+0xfQ+Ufz EWMAoJhCmRlybh4j1kgdqK88tX+aWEAN =lIRB -----END PGP SIGNATURE----- --MzUVogtTSRhL5bvu--