I haven't had the time to do anything other than look briefly
at your patches.  However, I recently did hack my kernel and
fsck tools up to mount some UFS cdroms (NeXTstep OS
distribution media).

If I recall from my investigation there were at least
the following potentially independent sources of block size:
  . units based on a 512 byte DEV_BSIZE
  . units based on the ffs superblock (see FFS_DEV_BSIZE below)
  . units based on the disklabel d_secsize
     ( this should always match the hardware device)

At the time, I found the following definitions useful:
  
  #define FFS_DEV_BSHIFT(fs) ((fs)->fs_fshift-(fs)->fs_fsbtodb)
  #define ffs_btodb(fs, b)   ((b) >> FFS_DEV_BSHIFT(fs))
  #define ffs_dbtob(fs, db)  ((db) << FFS_DEV_BSHIFT(fs))
  #define FFS_DEV_BSIZE(fs)  ffs_dbtob(fs,1)

I remember facing a couple of decisions about what units
quotas and free block counts were kept in.  Can you brief me
on decisions you made regarding these counters when authoring
your patches?  Do you have a rational for your choice?

Do you agree with my list of independent sources of block
size?  Are there any other fundamental ones not derived
from the above three?  Should we create a list of derived
indications of block size and which fundamental block
size they should be derived from?

I'll try to look at your patches, although it probably
won't happen this week.

Darrin