Date:        Fri, 07 Jun 2002 15:52:43 -0700
    From:        Trevin Beattie <trevin@xmission.com>
    Message-ID:  <3.0.32.20020607155218.00690eb0@clay.wh.ca.us>

  | I've been poring over the mkfs.c code to make sure there are no references
  | to DEV_BSIZE (as that value is not stored on disk), and I came across the
  | following at line 899:
  | 
  | 	node.di_blocks = btodb(fragroundup(&sblock, node.di_size));
  | 
  | A quick grep through the ffs code confirmed that di_blocks is assumed to be
  | in units of DEV_BSIZE.  This may cause problems if, as Bill has suggested,
  | a drive is transferred to another system where the kernel's value of
  | DEV_BSIZE is different.  Am I mistaken, or does anyone have a suggestion on
  | how to fix it without breaking existing implementations?  Why doesn't
  | di_blocks simply count the number of fragments?

Since no-one else answered this, and since di_blocks was my code
originally, a long long time ago, perhaps I can explain what is
going on there.

The theory is that di_blocks is in very well known constant units,
that are known by everyone.   If the count was in units of fragments
then applications (like du, ls) that extract the information would
need to have a way to know the fragment size before they could use
the information.

So, di_blocks isn't really supposed to be in DEV_BSIZE units, it is
supposed to be in 512 byte block units.   But it happens that at the
time, DEV_BSIZE==512 was one of the unchangable constants of the
universe (kind of like pi=3.14159... or NULL=0) and the distinction
between things wanting the constant number, and things wanting device
blocksize units was very much blurred (as you're discovering).

An alternatiive implementation might have had di_bsize recorded in
frags in the filesystem, and then converted to a well known constant
unit in stat() (etc) before being made visible to average userland
utilities.   That was never considered at the time this was being
implemented, there simply was no motivation to look into things that
deeply.

What's important I guess is that stat() returns a count of 512 byte
blocks, however you want to make the filesystem (and filesystem
cognisant utilities) behave here.

kre