While writing my ufs filesystem resizer (see my recent note to
current-users), I discovered some odd things about ufs, fsck, and
dumpfs.  Could some kind person tell me which of these are deliberate,
which are historical accidents, which are bugs, etc?  In particular,
which call for send-pring?

- If the filesystem size is an exact multiple of the cylinder group
    size, cg_ncyl in the last cg is 0, rather than the correct value
    (ie, fs_cpg).

- fsck demands that the cylinder group bitmaps be, relative to the
    struct cg, exactly where mkfs would put them.  (If you, say, move
    the cg_blkfree() bitmap to after all the others (and update the cg
    fields to point to the new locations), fsck will complain even
    though the filesystem is in fact fine.)

- fsck requires that all unused bits in the cg summary bitmaps be zero
    bits, regardless of whether this means "free" (eg, cg_inosused())
    or "allocated" (eg, cg_blksfree()).  (If the number of bits in the
    map is not a multiple of eight, there will be some unused bits in
    each cg; if the last cg is not a full cg, there will be more unused
    bits for that cg.)

- fsck requires that any unused bytes in the cg (eg, the bytes added to
    align cg_clustersum() to an int32_t boundary) be zero.

- dumpfs does not dump unused bits or bytes.  Combined with the
    foregoing, we see we can have the discouraging spectacle of a
    filesystem that fsck claims is defective, but for which dumpfs
    produces identical output before and after fsck "fixes" it.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu