From owner-freebsd-fs@FreeBSD.ORG Fri Sep 21 18:10:23 2007 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 69F9016A419; Fri, 21 Sep 2007 18:10:23 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.freebsd.org (Postfix) with ESMTP id F39DA13C4A5; Fri, 21 Sep 2007 18:10:22 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c220-239-235-248.carlnfd3.nsw.optusnet.com.au (c220-239-235-248.carlnfd3.nsw.optusnet.com.au [220.239.235.248]) by mail11.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l8LIAJpc028903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Sep 2007 04:10:21 +1000 Date: Sat, 22 Sep 2007 04:10:19 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Gary Palmer In-Reply-To: <20070921133127.GB46759@in-addr.com> Message-ID: <20070922022524.X43853@delplex.bde.org> References: <46F3A64C.4090507@fluffles.net> <46F3B4B0.40606@freebsd.org> <20070921131919.GA46759@in-addr.com> <20070921133127.GB46759@in-addr.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@FreeBSD.org, Ivan Voras Subject: Re: Writing contigiously to UFS2? 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: Fri, 21 Sep 2007 18:10:23 -0000 On Fri, 21 Sep 2007, Gary Palmer wrote: > On Fri, Sep 21, 2007 at 03:23:20PM +0200, Ivan Voras wrote: >> Gary Palmer wrote: >> >>> Presumably by using the -c parameter to newfs. >> >> Hm, I'll try it again later but I think I concluded that -c can be used >> to lower the size of cgs, not to increase it. Yes, it used to default to a small value, but that became very pessimal when disks became larger than a whole 1GB or so, so obrien changed it to default to the maximum possible value. I think it hasn't been changed back down. > A CG is basically an inode table with a block allocation bitmap to keep > track of what disk blocks are in use. You might have to use the -i > parameter to increase the expected average file size. That should > allow you to increase the CG size. Its been a LONG time since I looked > at the UFS code, but I suspect the # of inodes per CG is probably capped. The limit seems to be only that struct cg (mainly the struct hack stuff at the end) fits in a single block. The non-struct parts of this struct consist mainly of the inode, block and cluster bitmaps. The block bitmap is normally the largest by far, since it actually maps fragments. With 16K-blocks and 2K-frags, at most 128K frags = 256MB of disk can be mapped. I get 180MB in practice, with an inode bitmap size of only 3K, so there is not much to be gained by tuning -i but more to be gained by tuning -b and -f (several doublings are reasonable). However, I think small cg's are not a problem for huge files, except for bugs. Bruce