linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: flar@allandria.com
To: nicoya@apia.dhs.org (Tony Mantler)
Cc: geert@linux-m68k.org (Geert Uytterhoeven),
	khalfmann@libra.de (Halfmann Klaus),
	linux-fsdevel@vger.kernel.org ('linux-fsdevel@vger.kernel.org '),
	linuxppc-dev@lists.linuxppc.org
	('linuxppc-dev@lists.linuxppc.org '), olh@suse.de ('Olaf Hering')
Subject: Re: Status of HFS+ support
Date: Fri, 15 Sep 2000 22:01:06 -0700 (PDT)	[thread overview]
Message-ID: <200009160501.WAA02418@marcus.allandria.com> (raw)
In-Reply-To: <v04003a00b5e80ad96727@[24.70.162.14]> from "Tony Mantler" at Sep 15, 2000 12:40:38 PM


Tony Mantler wrote:
> Checking an hfs or hfs+ filesystem is very very easy.

Well, I don't know that I'd call it very easy, but it's certainly easier
than trying to actually fix it. :)

> I could picture walking down the catalog btree and check to see that the
> sidelinks and downlinks all agree on which node they're pointing at, and
> while you're at it, make sure the nodes don't point to garbage.
>
> You'd then probably repeat that procedure on the Extents btree.
>
> After that's done, you'd probably walk the leaf nodes of the catalog tree
> to check that the filesystem heiarchy is still sane. After that, it would
> probably follow to walk the leaf nodes in the extents btree and check for
> overlaps, then compare it with the volume bitmap.
>
> There's probably a few other checks that would be good too, like checking
> for stale extents records or something.

That all sounds reasonable. Probably wouldn't even take that long, and
would likely prove the correctness or incorrectness of the code in some
instances. The thing that would be a pain to check but very important
is to check the sorting order in all trees. I may even try to get something
running this weekend if I get a chance.

> Repairing an HFS(+) drive is a whole other matter entirely. Saying "This
> ain't no journaling filesystem" would be an understatement of galactic
> proportions (which, I should add, would also make threading the filesystem
> very painful). Consider that when you insert a new leaf node into one of
> the btrees, you have at the absolute very least 5 pointers to update. Power
> goes out? oops, now 2 of those pointers are pointing at one node, and 2 are
> pointing at some other node, and one's full of garbage 'cause the HD didn't
> get a chance to write out the whole node. Which pointers are correct? who
> knows, I don't think apple ever documented a prefered serialization order
> for any of the fs changes.

Yes, it is a bit of a mess.

> imho, the only reliable way to repair a crashed HFS(+) drive is with a hex
> editor.

Well, automated tools can fix some of the damage. I've had good luck fixing
drives with Norton Utilities, although there are some problems it chokes on.

	Brad Boyer
	flar@pants.nu


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2000-09-16  5:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-15  6:45 Status of HFS+ support Halfmann, Klaus
2000-09-15  7:03 ` Alexander Viro
2000-09-15 14:12   ` Juan J. Quintela
2000-09-15 13:07 ` Geert Uytterhoeven
2000-09-15 17:40   ` Tony Mantler
2000-09-16  5:01     ` flar [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-07-31  6:35 Status of HFS+ Support Halfmann, Klaus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200009160501.WAA02418@marcus.allandria.com \
    --to=flar@allandria.com \
    --cc=geert@linux-m68k.org \
    --cc=khalfmann@libra.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linuxppc-dev@lists.linuxppc.org \
    --cc=nicoya@apia.dhs.org \
    --cc=olh@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).