Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!ukc!sys.uea!jrk
From: jrk@sys.uea.ac.uk (Richard Kennaway CMP RA)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Missing megabytes
Message-ID: <477@sys.uea.ac.uk>
Date: 14 Mar 89 12:29:44 GMT
References: <457@sys.uea.ac.uk> <7550@polya.Stanford.EDU> <27058@apple.Apple.COM>
Reply-To: jrk@uea-sys.UUCP (Richard Kennaway)
Organization: University of East Anglia, Norwich
Lines: 41

Thanks to those who responded to my query about the missing megabytes.

[Recap for those who didnt see the message but might encounter the same
problem:  I had a program that finds the number of blocks in use on a
disc from information returned by PBHGetVInfo.  It also calculates what
should be the same information by using indexed calls of PBHGetCatInfo to
discover the size of every file on the volume and adding up their sizes,
remembering to first separately round up the lengths of the data and resource
forks of each file to a multiple of block size.  But for two hard discs I
tried this on, the latter figure was smaller than the former, on one by ~300
1k blocks and on the other by ~1700.  The strange aspect was that for a
third hard disc, the two figures always came out identical, ruling out
explanations based on the presence of housekeeping info which might be
included in the former figure and excluded from the latter.]

The solution came from keith@Apple.COM (Keith Rollin), who in article
<27058@apple.Apple.COM> writes:
>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:
...
>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.

That must be it.  I ran Disk First Aid, and it recovered the missing blocks.
I then tried out my program on some other hard discs around the department.
In every case I found at least a few missing blocks, recoverable with Disk
First Aid.  Looks like it's a good idea to run DFA occasionally.  Perhaps
the allocation map is getting damaged by software under development crashing
frequently in horrible ways.  I have done a lot more programming on the disc
that had the 1700 missing blocks than on the one that matched exactly.

In fact, the disc that had the 1700 block deficit still has 6 missing blocks,
but this probably isnt serious.  Disk First Aid reports no problems.  I
would guess that these are permanent defects on the disc, that arent
counted either as free blocks or as belonging to any file.
-- 
Richard Kennaway                SYS, University of East Anglia, Norwich, U.K.
uucp:	...mcvax!ukc!uea-sys!jrk	Janet:	kennaway@uk.ac.uea.sys