Writing contigiously to UFS2?

[Rick C. Petty]

On Wed, Sep 26, 2007 at 05:59:24PM +1000, Bruce Evans wrote:
> On Tue, 25 Sep 2007, Rick C. Petty wrote:
> 
> That's insignificantly more.  Even doubling the size wouldn't make much
> difference.  I see differences of at most 25% going the other way and

Some would say that 25% difference is significant.  Obviously you disagree.

>     4K blocks, 512-frags -e 512  (broken default):     40MB/S
>     4K blocks, 512-frags -e 1024 (broken default):     44MB/S
>     4K blocks, 512-frags -e 2048 (best), kernel fixes: 47MB/S
>     4K blocks, 512-frags -e 8192 (try too hard), kernel fixes
>        (kernel fixes are not complete enough to handle this case;
>        defaults and -e values which are < the cg size work best except
>        possibly when the fixes are complete):          45MB/S
>     16K blocks, 2K-frags -e 2K   (broken default):     50MB/S
>     16K blocks, 2K-frags -e 4K   (fixed default):      50.5MB/S
>     16K blocks, 2K-frags -e 8K   (best):               51.5MB/S
>     16K blocks, 2K-frags -e 64K  (try too hard):       < 51MB/S again

Are you talking about throughputs now?  I was just talking about space.
Time and space are usually mutually-exclusive optimizations.

> >Here might be an interesting experiment to try.  Write a new version of
> >/usr/src/sbin/newfs/mkfs.c that doesn't have the restriction that the free
> >fragment bitmap resides in one block.  I'm not 100% sure if the FFS code
> >would handle it properly, but in theory it should work (the offsets are
> >stored in the superblocks).  This is the biggest restriction on the CG
> >size.  You should be able to create 2-4 CGs to span each of your 1TB
> >drives without increasing the block size and thus minimum allocation unit.
> 
> In theory it won't work.  From fs.h:
> 
> %%%
> /*
>  * The size of a cylinder group is calculated by CGSIZE. The maximum size
>  * is limited by the fact that cylinder groups are at most one block.
>  * Its size is derived from the size of the maps maintained in the
>  * cylinder group and the (struct cg) size.
>  */
> %%%

Debug code, not comments!  :-P

> Only offsets to the inode blocks, etc. are stored in the superblock.

Yes, the offset to the cylinder group block and the offset to the inode
block are in the superblock (struct fs).  It wouldn't be too difficult to
tweak the ffs code to read in CGs larger than one block, by checking the
difference between fs_iblkno and fs_cblkno.  I'm saying it's theoretically
possible, although it will require tweaks in ffs code.  Again, I think it's
worth investigating, especially if you believe there are performance
penalties for having block sizes greater than the kernel buffer size.

-- Rick C. Petty