demystifying HFS bad blocks
VAlexa
blocks, there is unexplainably low information available with a search
for kHFSBadBlockFileID yielding a single posting in cocoa-dev that
states that :
"You create one or more records in the Extents Overflow B-tree for
file ID 5 (kHFSBadBlockFileID), fork 0 (i.e. the data fork). Since
there is no entry for the bad blocks "file" in either the MDB or
catalog, the first record would have its startBlock set to 0 (i.e.
offset of 0 blocks into the "file"). If you need other discontiguous
bad block extents, you would create additional records."
and a few references in Amit Singh's Mac OS X internals.
The only information from apple that i can find is in
http://support.apple.com/kb/TA21976?viewlocale=en_US which dates from
2003 and states :
"ATA (IDE) drives internalize tracking and sparing of bad blocks.
Drive Setup and ATA drivers thus have little control over this
process. Which is why the low-level format option is dimmed when
initializing an ATA (IDE) hard drive. Reallocation (sparing) of bad
blocks that the ATA drive tracks will occur when the block is
subsequently written to. Thus the best way to force the drive to
reallocate bad blocks is to initialize using the write zeros feature."
My main question is, is there any way to synchronize the HFS bad
blocks file with the list of the bad blocks determined internally by
the drive, given that there would be a way to access the internal
drive data on bad blocks.
Alastair Houghton
> My main question is, is there any way to synchronize the HFS bad
> blocks file with the list of the bad blocks determined internally by
> the drive, given that there would be a way to access the internal
> drive data on bad blocks.
No, and there's no point either. The blocks the drive knows about are spared (or mapped out) and can't be accessed from normal software.
Kind regards,
Alastair.
Vlad Alexa
marked as bad in HFS it needs to be unknown as a bad block by the
drive, which does not make a lot of sense even if there is a way to
unidirectionally sync the HFS bad blocks list > drive's bad blocks
list.
I can only guess that the HFS bad blocks system was designed when
drives did not have internal handling for it themselves.
On Sep 7, 10:04 pm, Alastair Houghton <alast...@alastairs-place.net>
wrote:
Eric Anderson
> Thanks, i take it this means that for a block to be accessed and
> marked as bad in HFS it needs to be unknown as a bad block by the
> drive, which does not make a lot of sense even if there is a way to
> unidirectionally sync the HFS bad blocks list > drive's bad blocks
> list.
>
> I can only guess that the HFS bad blocks system was designed when
> drives did not have internal handling for it themselves.
If the drive supports S.M.A.R.T. then I think you can request the list of bad blocks from the drive itself.
(this post precedes my intro.. which will come.. soon..)
Eric
Vlad Alexa
Count, not where those individual blocks are.
Alastair Houghton
> Thanks, i take it this means that for a block to be accessed and
> marked as bad in HFS it needs to be unknown as a bad block by the
> drive, which does not make a lot of sense even if there is a way to
> unidirectionally sync the HFS bad blocks list > drive's bad blocks
> list.
>
> I can only guess that the HFS bad blocks system was designed when
> drives did not have internal handling for it themselves.
Yes, that's correct. Various other filesystems designed for use on consumer systems (especially those that were used on floppy disks) have this feature also, but generally speaking I'd expect the bad block lists to be empty for modern hard disks.