Date: Sat, 22 Sep 2007 04:10:19 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Gary Palmer <gpalmer@FreeBSD.org> Cc: freebsd-fs@FreeBSD.org, Ivan Voras <ivoras@FreeBSD.org> Subject: Re: Writing contigiously to UFS2? Message-ID: <20070922022524.X43853@delplex.bde.org> In-Reply-To: <20070921133127.GB46759@in-addr.com> 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> <20070921133127.GB46759@in-addr.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070922022524.X43853>