Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!apple!keith
From: keith@Apple.COM (Keith Rollin)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Missing megabytes
Message-ID: <27058@apple.Apple.COM>
Date: 10 Mar 89 04:30:03 GMT
References: <457@sys.uea.ac.uk> <7550@polya.Stanford.EDU>
Organization: Apple Computer Inc, Cupertino, CA
Lines: 57

In article <7550@polya.Stanford.EDU> kaufman@polya.Stanford.EDU (Marc T. Kaufman) writes:
>In article <457@sys.uea.ac.uk> jrk@s1.UUCP (Richard Kennaway) writes:
>>I am writing a program which, among other things, makes a directory
>>listing of a volume.  There is a strange discrepancy in the
>>information it collects.
>
>>When it scans through all the files and folders with PBHGetCatInfo
>>in the usual way, it always finds exactly the right number of files and
>>folders, but the sum of their sizes is sometimes less than the
>>calculated number of used blocks.
>
>You should be aware that disk space is allocated in "Clumps" of size ioVClpSiz,
>where the clump size is chosen so that [disk size / clump size] < 65535,
>which is the maximum number of allocation blocks that the file system can
>handle.  In addition, there is overhead for the allocation block bit map and
>the allocation and directory B-trees, which will not be reflected in the
>simple summation of file sizes.

You are confusing clump size (drClpSiz) with the allocation block size 
(drAlBlksiz). The clump size is used to determine how many contiguous 
allocation blocks to assign to a file as it is being written. This is done to 
reduce fragmentation.  Richard is correctly taking into account the allocation 
block size.

I don't think that the clump size or volume bitmap come into play here. After 
a file is closed, the extent is "cut back" to just the right size needed. Also, 
the volume bitmap is not included in the allocation block section of the hard 
disk; the allocation blocks start just after the bitmap. Compare the values of
drVBMStart and drAlBlSt to see this.

I am actually surprised that Disk 2 matched at all. I would have thought that
the two figures would have differed by the sizes of the catalog and extents
B*-trees in all cases. Right now, I am considering 3 scenarios:

1) The 2 sizes should never match: this is because the method used to add up
the files' sizes will never take into account the catalog and extents B*-trees.

2) The 2 sizes should always match: this assumes that the size of the 2
B*-trees is subtracted from the total number of allocation blocks. In this
case, the discrepencies encountered on Disks 1 & 3 could be explained by a
blown allocation bitmap. Try running Disk First Aid.

3) The 2 sizes should sometimes match: this assumes that there are 
characteristics of a fragmented disk that would account for this. For 
instance, a fragmented disk will have an extents B*-tree. For some bizarre 
reason, this could account for the difference.

Off the top of my head, I don't know which one of these is more likely (if any
of them are right at all).


------------------------------------------------------------------------------
Keith Rollin  ---  Apple Computer, Inc.  ---  Developer Technical Support
INTERNET: keith@apple.com
    UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith
"Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions