On Mon, 24 Jun 2002, Darrin B. Jewell wrote:

> 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)

Note: those are file system blocks aka frags.

>   . units based on the disklabel d_secsize
>      ( this should always match the hardware device)

Note: the latter isn't necessarily true. If you take a disk image & move
it to another system, it may change. Folks wish to continue using the
disklabel number.

> At the time, I found the following definitions useful:
>
>   #define FFS_DEV_BSHIFT(fs) ((fs)->fs_fshift-(fs)->fs_fsbtodb)

That should be a constant in the ufs mount structure (the in-kernel
thing). We don't need to subtract those constants every time; they aren't
going to change.

>   #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?

He chose the design philosophy I (ehm strongly) suggested. :-)

NetBSD 1.5 only supported file systems on disks where the physical sector
size == DEV_BSIZE. So anything that uses DEV_BSIZE and is stored on-disk
should really use the fs-declared sector size (FFS_DEV_BSHIFT() above,
though Trevin used a different name).  When formatting a file system,
"FFS_DEV_BSHIFT()" will equal the sector size of the media. That fs can
later be moved around, because the superblock has enough info to recreate
"FFS_DEV_BSHIFT()".

> 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?

There actually is one more. The buffer cache is kept in units of
DEV_BSIZE. You can have a file system that was made with a DEV_BSIZE=1024
get moved to a kernel with DEV_BSIZE=512. After these changes, we want
that fs to work. So that means that when translating ffs_btodb() outputs
to buffer cache offsets, we need to use a conversion to bridge between
them. :-)

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

I think I'll be on the same timeline.

Take care,

Bill