At 10:23 AM 6/26/2002 -0700, Bill Studenmund wrote:
>On Wed, 26 Jun 2002, Darrin B. Jewell wrote:
>> Ok, I have a UFS filesystem image from a NeXT 1k scsi disk as well
>> as the UFS filesystem image from the NeXTstep 3.3 install CD (2k media)
>> If there is a particular analysis you would like, please let me know.
>> I will examine the inode again and let you know what I see.  I hope to
>> have the time this weekend or over the upcoming holiday.
>
>The main thing I had in mind is the file size in blocks and bytes should
>be in there, so we should be able to get the block size. :-)

Okay, I finally got around to dumping out my NeXTSTEP-formatted optical
disk again (2KB/sector, 2KB fragments, 8KB blocks), and looked up the inode
blocks.  Here's what I found:

inode 2: size=0x400, blocks=1
inode 3: size=0x2000, blocks=4
inode 4: size=0x173569a, blocks=0x2e78
inode 5: size=0, blocks=0
inode 6: size=0x10b3, blocks=3
inode 7: size=0x79d05da, blocks=0xf3c8
inode 8: size=0xb, blocks=1
inode 9: size=0x5d470d6, blocks=0xbaac
inode 10: size=0x15ec6f, blocks=0x2c4
inode 11: size=0x25777, blocks=0x50

I think that's enough to demonstrate that in NeXTSTEP, di_blocks is stored
in units of disk blocks.  However, as both sectors and fragments are 2K, I
can't be 100% certain which one it is.  Wish I had my Cube set up so I
could reformat a disk with a different fragment size. :-P  I used to have a
NeXTSTEP partition on my '486 too, but that drive died last year. :-{

It's interesting to note that (RedHat) Linux has an option to mount a
nextstep-cd.  So I tried it, and compared "ls -l" with "du -k" for a couple
of files.  Guess what?  Linux' du reported only 1/4 of the actual file
size!  Guess they didn't quite get it right.

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