From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 22 15:31:52 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA41A1065673 for ; Mon, 22 Aug 2011 15:31:52 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.gmx.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id 65B238FC1D for ; Mon, 22 Aug 2011 15:31:52 +0000 (UTC) Received: (qmail 5357 invoked by uid 0); 22 Aug 2011 15:31:50 -0000 Received: from 67.206.161.243 by rms-us013.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Mon, 22 Aug 2011 15:31:48 +0000 From: "Dieter BSD" Message-ID: <20110822153149.227910@gmx.com> MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: XURhem0Q+Uf1dUjTB2Vyu5x/SDc4NMzy Subject: optimum fs param sizes (was: ZFS installs on HD with 4k physical...) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 15:31:52 -0000 >> I guess formatting the filesystem for 4k sectors on a 512b drive would still >> work but it would be suboptimal.  What would the performance penalty be in >> reality? > > It would be suboptimal but only for the slight waste of space that would > have otherwise been reclaimed if the block or fragment size remained 512 > or 2K. This waste of space is insignificant for the vast majority of > users and there are no performance penalties, so it seems that switching > to 4K sectors by default for all file systems would actually be a good idea. If you have large files, then large block/frag sizes waste less space than small ones.  Remember that keeping track of all those blocks and frags has overhead, and that overhead can waste more space than you save at the end of files. Is anyone looking at extending the range of tuning variables for FFS? Allowing even larger block/frag sizes would be useful, as well as larger cylinder groups and fewer inodes.  Fsck runs a *lot* faster with fewer inodes.  The expected average file size and expected average number of files per directory limits could use work as well. newfs -e 100000000 -b 16384 -f 2048 -g 67108864 -h 16 -i 67108864 -U -o space -L 58data /dev/ada9p1 density reduced from 67108864 to 3676160 /dev/ada9p1: 2861588.5MB (5860533100 sectors) block size 16384, fragment size 2048        using 12754 cylinder groups of 224.38MB, 14360 blks, 64 inodes.        with soft updates A cylinder group size of 224.38MB is just insanely small with today's disk and file sizes. IIRC the block size limit is 64K, but there was some bug with using block/frag larger than 16K/2K.  Even 64K is too small.