Writing contigiously to UFS2?

[Bruce Evans]

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