Re: APFS: FSTREE oids on sealed volume
Re: APFS: FSTREE oids on sealed volume
- Subject: Re: APFS: FSTREE oids on sealed volume
- From: Joe Sylve via Filesystem-dev <email@hidden>
- Date: Wed, 28 Oct 2020 17:18:02 -0500
Thank you for the clarification, Mike! This was very helpful.
On Wed, Oct 28, 2020, 17:04 Mike Mackovitch <email@hidden> wrote:
> On Wed, Oct 28, 2020 at 03:07:20PM -0500, Joe Sylve via Filesystem-dev
> wrote:
> > I have a question regarding the on-disk structure of sealed system
> volumes
> > in macOS 11. When parsing the sealed system volume, I'm seeing non-leaf
> > fstree nodes whose binv_child_oid does not correspond to an object id
> that
> > is found in the volume's OMAP. Parsing the non-sealed volumes works as
> > expected.
> >
> > I can't find anything in the latest documentation that suggests that the
> > child object ids in sealed volume fstrees should be handled any
> > differently, and the flags in the tree suggest that these are virtual
> > object ids.
> >
> > Is there another layer of indirection or a different omap that I need to
> > parse to link the child nodes on sealed volumes?
>
> Unfortunately, it looks like the new documentation left out some details.
>
> The binv_child_oid values of hashed trees are relative to the root node's
> OID.
> So, if the root node's OID is X, when you look the child up in the OMAP,
> you'll
> look for object "X + binv_child_oid".
>
> The binv_child_hash fields are actually variable-sized up to the
> documented max.
> The size of that field will match the size of the hash algorithm being
> used.
>
> Also, BT_NOHEADER does not mean that the btree node objects don't have
> object
> headers (like OBJ_NOHEADER means), but rather that the btree node headers
> have
> the object header portion zeroed out.
>
> HTH
> --macko
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden