From: Thomas Gleixner <tglx@linutronix.de>
To: Wookey <wookey@aleph1.co.uk>
Cc: linux-mtd@lists.infradead.org
Subject: Re: Finding which block 'contains' a missing inode
Date: Thu, 23 Sep 2004 09:10:56 +0200 [thread overview]
Message-ID: <1095923456.2925.55.camel@thomas> (raw)
In-Reply-To: <20040923004331.GA24050@xios>
On Thu, 2004-09-23 at 02:43, Wookey wrote:
> Hello people, I have a JFFS2 NAND rootfs which is giving a single
> 'Eep. Child "gpe-filemanager.desktop" (ino #3324) of dir ino #3035 doesn't
> exist!' error.
>
> I'd like to know if there is a way of finding out either form the live fs or
> from the jffs2 image file which block the offending inode/file should have
> been on?
Get a binary image from the chip and process it with
jffs2dump -vc binimg >img.dmp
The dump should tell you where which node/fragment resides
> Background: The kernel indicated one 'bad erase block' that is under this
> fs, but flasheraseall found no problem, and nandwrite did not skip that
> block. I worry that the block in question doesn't actually have the right
> data in it - if it corresponded to the above inode then I'd be sure I had
> located the problem.
What do you mean ? "kernel indicated one 'bad erase block'".
How is it indicated ?
> There is also a 'normal' bad block (which gives an IO error when
> flasheraseall tries to erase it) - this _is_ skipped by nandwrite as expected.
Are you using current MTD code ?
The code checks the device for bad blocks when nand_scan is called. It
usually prints the bad block information. Is this your 'normal' bad
block ?
tglx
next prev parent reply other threads:[~2004-09-23 7:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-23 0:43 Finding which block 'contains' a missing inode Wookey
2004-09-23 7:10 ` Thomas Gleixner [this message]
2004-09-23 12:33 ` Wookey
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=1095923456.2925.55.camel@thomas \
--to=tglx@linutronix.de \
--cc=linux-mtd@lists.infradead.org \
--cc=wookey@aleph1.co.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.