HEADS UP: UFS2 now the default creation type on 5.0-CURRENT

[David Schultz]

On Mon, Apr 21, 2003, Bruce Evans wrote:
> On Mon, 21 Apr 2003, David Schultz wrote:
> 
> > The cgbase hack should only limit the size of the filesystem, not
> > the disk location.  It occurs to me that with a little more
> > hackery, we can avoid the limitation entirely.  If we revert to
> > the 64-bit cgbase() and un-inline it, boot2 goes from 19 bytes
> > available to -9 bytes.  Add a kludge to factor out a few 64-bit
> > multiply-adds and we're back to 3 bytes available.  (I'm sure
> > there are cleaner ways to save 9 bytes.)  An untested unpolished
> > diff follows.
> 
> I played with similar changes, but didn't finish them.
> 
> > Index: ufsread.c
> > ===================================================================
> > RCS file: /cvs/src/sys/boot/common/ufsread.c,v
> > retrieving revision 1.11
> > diff -u -r1.11 ufsread.c
> > --- ufsread.c	25 Feb 2003 00:10:20 -0000	1.11
> > +++ ufsread.c	21 Apr 2003 10:10:01 -0000
> > ...
> > @@ -47,11 +59,11 @@
> >  ...
> > -#define FS_TO_VBA(fs, fsb, off) (fsbtodb(fs, fsb) + \
> > -    ((off) / VBLKSIZE) * DBPERVBLK)
> > +#define FS_TO_VBA(fs, fsb, off)	ma((off) / VBLKSIZE, DBPERVBLK, \
> > +	fsbtodb((fs), (fsb)))
> 
> The division by VBLKSIZE should probably be a shift.  ufsread.c has
> VBLKSHIFT and uses it for all multiplications and divisions by VBLKSIZE
> except this one.  gcc can't optimize to just a shift since all the
> types are signed and C99 specifies that division of negative integers
> by positive ones has the usual hardware brokenness.

As I recall, signed division gets optimized into a sign test, some
bit fiddling for negative numbers, and a division.  The additional
cost is nominal if you only care about speed, but I'm sure using a
shift directly would save a few more bytes.