On Thu, 20 Jun 2002, Trevin Beattie wrote:

> The problem with that is 'db' and 'fsb' are ambiguous; especially 'db',
> because  DEV_BSIZE is NOT equal to the sector size.  And as currently
> written, the db macros *don't* convert to/from DEV_BSIZE; they use the
> sector size.

Well, sort of.  Currently DEV_BSIZE and d_secsize are both 512.  Once
d_secsize can be anything other than 512 and have mountable ufs on it,
DEV_BSIZE becomes meaningless and we should be converting to and from
d_secsize units---which is what your patches do, right?

On the other hand (and the reason I wrote "logical" in the comment): when
I came up with the feature set for the LFSv2 disk layout, one of my goals
was to do away with implicit encoding of DEV_BSIZE in the data structures;
I wanted to be able to dd a filesystem to another disk with a different
physical sector size, and (assuming that the new sector size is less than
the filesystem fragment size) have it Just Work.

If it turns out that this is unreasonably difficult, it's fairly low on
the list, but I *think* all we would need to do is adjust the *todb/dbto*
macros at filesystem mount time, and put them back each time we write the
superblock.

> But if you want to do that, remember that many members of struct dlfs also
> use the unit identifiers 's', 'd', 'b', 'f', 'frag', 'seg', 'fsb', 'blk',
> and 'db'; and the one that are there are not always consistent (e.g.,

Right.  Some of those should go ("d", for example, should be "fsb").
Some of them would go but have to stay because they correspond to
historical UFS nomenclature (e.g., "inopb").

There may be a little confusion as well because some of those units (e.g.,
"sn") refer to addresses and *cannot* be interpreted as sizes without a
corresponding offset; segment zero could easily start at block 16.

> ffshift).  IMO, the affix 'db' should be eliminated entirely from struct
> dlfs in favor of one that denotes sector size.

But see my comment above, it is intended to mean logical sector size.

> I just got an idea: maybe I can add a few more members to the end of struct
> lfs (presuming that only the kernel uses it) denoting the log2(size) of

This is an excellent idea.  struct lfs is only used by the kernel.

> more.  (Four of the existing macros use three terms; the fix for lfs_ifind
> (lfs_inode.c:138) requires four.)

What is the "fix" for lfs_inode.c:138 ?

						Konrad Schroder
						perseant@hhhh.org