Writing contigiously to UFS2?
brde at optusnet.com.au
Fri Sep 21 11:10:23 PDT 2007
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
More information about the freebsd-fs