Re: [OT] bad records in HFS+ volume
Re: [OT] bad records in HFS+ volume
- Subject: Re: [OT] bad records in HFS+ volume
- From: "Gerriet M. Denkmann" <email@hidden>
- Date: Fri, 30 Jul 2004 01:05:30 +0200
On 29.07.2004, at 23:26, Dave Camp wrote:
>
On Jul 29, 2004, at 12:57 PM, Gerriet M. Denkmann wrote:
>
>
> The Extents Overflow File of one of my HFS+ partitions has a few
>
> records referencing fileIDs (aka NSFileSystemNumber or unique
>
> catalog node ID (CNID) ) which do not exist (i.e. are not in the
>
> Catalog File).
>
>
>
> Disk Utility (and fsck) do have no problem with this and report no
>
> error.
>
>
If the CNIDs are low numbers, those might be entries for other file
>
system structures which are not tracked in the Catalog (overflow
>
entries for the catalog tree, extents tree, volume bitmap, bad blocks,
>
hot zone stuff, etc).
No, the numbers were like 1359048 and similar. Must be some files which
were created a year ago.
>
>
Otherwise, I'd be surprised that Disk Utility did not flag the orphan
>
extents as errors. While they don't hurt anything (assuming the volume
>
bitmap is in sync with the extents), it's space that's essentially
>
wasted.
No the space is not wasted. The space claimed by these dead extents (at
least most of it) is allocated for other (existing) things.
>
>
How do you know you have orphaned extents?
Because I wrote a small app, which checks a HFS+ volume for all sort of
consistencies. Same as fsck, only it does no repairing, just reports.
>
>
> But what will happen when the CNID wraps around and these
>
> non-existing iIDs will be used again?
>
> Will the file system notice that dead records exist in the Extents
>
> file and remove them?
>
> Or will a terrible confusion be the result?
>
>
>
> Currently I create about 1 million IDs per year, so the CNID
>
> wrap-around is not really imminent.
>
>
I'm not sure what happens when you exhaust the range of CNIDs (I've
>
not seen it done before). The filesystem keeps track of the last
>
number used and adds one to get the next number to use when a new file
>
or directory is created. Since there is no list of what's used and not
>
used (other than the hundreds of thousands of catalog entries) I'd
>
expect the filesystem to just return an error when you hit the last
>
one. If the filesystem can no longer just "add one" to determine the
>
next one, I would expect the overhead of determining what the first
>
unused CNID is to be too great.
Well, Apples technical note 1150 says:
"Typically, CNIDs are allocated sequentially, starting at
kHFSFirstUserCatalogNodeID. Versions of the HFS Plus specification
prior to Jan. 18, 2000, required the nextCatalogID field of the volume
header to be greater than the largest CNID used on the volume (so that
an implementation could use nextCatalogID to determine the CNID to
assign to a newly created file or directory). However, this can be a
problem for volumes that create files or directories at a high rate
(for example, a busy server), since they might run out of CNID values.
HFS Plus volumes now allow CNID values to wrap around and be reused.
The kHFSCatalogNodeIDsReusedBit in the attributes field of the volume
header is set to indicate when CNID values have wrapped around and
been reused. When kHFSCatalogNodeIDsReusedBit is set, the
nextCatalogID field is no longer required to be greater than any
existing CNID."
Kind regards,
Gerriet.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.