After looking through the mkfs code, I've got some more questions about the
superblock.  (Mostly, correct me if any of the following assumptions are
wrong.)

In <ufs/ffs/fs.h>, it looks like the location of the superblock is at a
constant byte offset into the partition (lines 62-70).

I'm assuming that fs_size and fs_dsize (number of blocks in filesystem) are
in terms of fs fragments, right?  And are fs_sblkno, fs_cblkno, fs_iblkno,
and fs_dblkno (all of type ufs_daddr_t) in terms of DEV_BSIZE blocks, or fs
fragments?  In my test filesystem, it appears that newfs wrote fs_sblkno
(and the block number of the super-block backup) in units of physical
sectors instead, which may explain why the mount procedure couldn't find
the superblock.  (Although it should have been looking at byte offset
0x2000 instead of a block/sector/DEV_BSIZE number.)

The superblock does not store the sector size of the underlying device.
This makes sense, since the sector size logically belongs to the device
(stored in the disk label for convenience), and probably should be
independent of the file system.  However, the superblock does contain other
variables -- fs_npsect, fs_nsect, and fs_spc -- which are both
device-dependent and in terms of physical sector size.  In light of the
fact that most modern drives (such as those using >512 Bps) don't have a
constant number of tracks per cylinder, are these variables really needed,
or can they be eliminated?  fs_ncyl and fs_ntrak are also device-dependent,
and by extension fs_cpg and fs_ncg may depend on the sector size as well.
Should they be?

I would think the macros fsbtodb and dbtofsb convert from fragment numbers
(logical blocks) to DEV_BSIZE blocks.  This would make it consistent with
the notion that b_blkno is always in units of DEV_BSIZE.  However, the
value of fs_fsbtodb written by newfs is in terms of physical sectors
instead.  Which is correct?

The macros NSPB and NSPF are documented as being in terms of DEV_BSIZE
units.  The macro CGSIZE makes use of fs_spc (with units of physical
sectors) and NSPF/NSPB (with units of DEV_BSIZE).  Obviously this breaks on
disks where the sector size != DEV_BSIZE.  Since the apparent intention of
the math is fragments (or fs blocks) per cylinder group, but the actual
result is (sectors * fragments) / (DEV_BSIZE * cgroup), should the
subexpression be multiplied by the number of DEV_BSIZE blocks per sector in
order to straighten out the units?

The macro cbtocylno also divides the block number (fsbtodb(), with units of
DEV_BSIZE?) by fs_spc (physical sectors / cylinder), giving a result in
DEV_BSIZE * cylinder / sector, instead of the desired cylinder number.  The
cbtorpos macro has a similar problem.

I would like to proceed by changing the definition of fs_spc to mean
DEV_BSIZE blocks per cylinder (in order to retain compatibility with
existing filesystems), and eliminate any expressions that mix tracks with
cylinders (i.e., cbtorpos).  Unless someone can think of a reason not to.
I'm also going to redefine anything else (in the file system structure)
that is in terms of sectors to be in terms of DEV_BSIZE blocks (except for
fs_nsect and fs_npsect), thus completely separating physical sector size
from the filesystem (except, of course, as a minimum bound for the fragment
size).

Along that line, and going with what Bill said about DEV_BSIZE and the
Convex system, I think we can give a useful meaning to the value of
DEV_BSIZE: it could be defined as the minimum block size supported by a
platform.

-----------------------
Trevin Beattie          "Do not meddle in the affairs of wizards,
trevin@xmission.com     for you are crunchy and good with ketchup."
      {:->                                     --unknown