From owner-freebsd-fs@FreeBSD.ORG  Fri Sep 21 13:31:28 2007
Return-Path: <owner-freebsd-fs@FreeBSD.ORG>
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 5D81E16A4D1;
	Fri, 21 Sep 2007 13:31:28 +0000 (UTC)
	(envelope-from gpalmer@freebsd.org)
Received: from noop.in-addr.com (unknown [IPv6:2001:5c0:8fff:fffe::214d])
	by mx1.freebsd.org (Postfix) with ESMTP id 2580613C461;
	Fri, 21 Sep 2007 13:31:28 +0000 (UTC)
	(envelope-from gpalmer@freebsd.org)
Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD))
	id 1IYibP-000MbM-Ch; Fri, 21 Sep 2007 09:31:27 -0400
Date: Fri, 21 Sep 2007 09:31:27 -0400
From: Gary Palmer <gpalmer@freebsd.org>
To: Ivan Voras <ivoras@freebsd.org>
Message-ID: <20070921133127.GB46759@in-addr.com>
Mail-Followup-To: Ivan Voras <ivoras@freebsd.org>, freebsd-fs@freebsd.org
References: <46F3A64C.4090507@fluffles.net> <46F3B4B0.40606@freebsd.org>
	<fd0em7$8hn$1@sea.gmane.org> <20070921131919.GA46759@in-addr.com>
	<fd0gk8$f0d$2@sea.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <fd0gk8$f0d$2@sea.gmane.org>
Cc: freebsd-fs@freebsd.org
Subject: Re: Writing contigiously to UFS2?
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Sep 2007 13:31:28 -0000

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.

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.