linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Ryan Cumming <ryan@completely.kicks-ass.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [BK PATCH] Add ext3 indexed directory (htree) support
Date: Thu, 26 Sep 2002 10:05:26 -0400	[thread overview]
Message-ID: <20020926140526.GB9400@think.thunk.org> (raw)
In-Reply-To: <200209252322.44389.ryan@completely.kicks-ass.org>

On Wed, Sep 25, 2002 at 11:22:41PM -0700, Ryan Cumming wrote:
> > > 8) I rebooted, and fsck said:
> > > "Directory inode 131073,block3,offset 528: Directory corrupted"
> > > I wasn't so lucky this time, and a good portion of my home directory got
> > > eaten.
> >
> > Against, what was the pathnmae to the inode #131073?
> /home/ryan (ugh)

One more thought.  The files in your directory weren't gone; they were
just moved to the lost+found directory, and you just lost their
name->inode numbers mapping.  This is recoverable, however, if you had
saved that information first.  

If you must test on filesystems with precious data (as opposed to
using scratch disks or loopback mounts), something which is really
useful to do in advance is to run the command:

	e2image -r /dev/hdXX /var/e2image/XXX.e2img

This will create a dump of all of the critical filesystem metadata,
including the directory blocks.  I sometimes ask people to send me
compressed e2image dump files when I need to debug a filesystem, since
it allows me to see all of the metadata, which is what I care about,
without getting need to send all of the data in the filesystem, which
(a) might be a privacy problem, and (b) makes the image file
significantly bigger to send over the network.

It's also useful for recovery purposes.  For example, you can run
debugfs on the e2image file, and use the ls command to see the
original directory, which would have allowed you to relatively easily
reconstruct the filenames of the files left in the lost+found
directory.

Actually, the easiest way to do it would be to write a quick perl or
python script to gether up all of the inode numbers of the files in
lost+found, and pass it to the debugfs's "ncheck" command, which will
map inode numbers to pathnames.  You can specify all of the inodes
ncheck at once:

	debugfs -R "ncheck ino1 ino2 ino3 ..." /var/e2image/XXX.e2img

Then just parse the output, and move the files from lost+found back to
their original location in your home directory.

In fact, what e2image can be so helpful that a wise distribution might
want to consider automatically running it at boot time, to save
critical filesystem metadata.  This could be used to reconstruct
filesystems and recover critical data in the case of various sorts of
hardware failure and/or kernel bugs.

							- Ted

  reply	other threads:[~2002-09-26 14:01 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-25 20:03 tytso
2002-09-25 20:34 ` Andreas Dilger
2002-09-25 20:41 ` Dave Jones
2002-09-25 21:08   ` Andreas Dilger
2002-09-25 21:34   ` Theodore Ts'o
2002-09-25 22:54 ` Jeff Garzik
2002-09-25 23:29   ` Theodore Ts'o
2002-09-25 23:45     ` Ryan Cumming
2002-09-26  3:27       ` Theodore Ts'o
2002-09-26  5:23         ` Ryan Cumming
2002-09-26  5:57           ` Theodore Ts'o
2002-09-26  6:22             ` Ryan Cumming
2002-09-26 14:05               ` Theodore Ts'o [this message]
2002-09-26  6:25             ` Ryan Cumming
2002-09-26 11:25               ` Daniel Egger
2002-09-26  7:41             ` Ryan Cumming
2002-09-26 13:23               ` Theodore Ts'o
2002-09-26 15:42               ` Theodore Ts'o
2002-09-26 19:08                 ` Ryan Cumming
2002-09-26 19:51                   ` Horst von Brand
2002-09-26 19:59                     ` Ryan Cumming
2002-09-26 22:04                   ` Theodore Ts'o
2002-09-26 22:53                     ` Ryan Cumming
2002-09-26 23:57                       ` Theodore Ts'o
2002-09-27  1:00                         ` Ryan Cumming
2002-09-27  3:24                           ` Theodore Ts'o
2002-09-27  4:12                         ` Andreas Dilger
2002-09-27  7:55                           ` Ryan Cumming
2002-09-28  1:20                           ` Ryan Cumming
2002-09-28  1:46                             ` Ryan Cumming
2002-09-28 14:13                             ` Theodore Ts'o
2002-09-28 14:18                               ` Theodore Ts'o
2002-09-28 22:35                                 ` Ryan Cumming
2002-09-28 17:27                               ` [Ext2-devel] " Andreas Dilger
2002-09-28 18:43                                 ` chrisl
2002-09-28 19:45                                 ` chrisl
2002-09-28 22:30                               ` Ryan Cumming
2002-09-29  7:03                               ` [PATCH] fix htree dir corrupt after fsck -fD chrisl
2002-09-29  8:16                                 ` Ryan Cumming
2002-09-29  8:36                                   ` Ryan Cumming
2002-09-30  2:46                                   ` Ryan Cumming
2002-09-29 14:13                                 ` Theodore Ts'o
2002-09-25 23:31 ` [BK PATCH] Add ext3 indexed directory (htree) support Daniel Egger
2002-09-26  0:32   ` Randy.Dunlap
2002-09-26  0:50 ` Aaron Lehmann
2002-09-26  3:28   ` Theodore Ts'o
2002-10-02  9:11 tytso

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=20020926140526.GB9400@think.thunk.org \
    --to=tytso@mit.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ryan@completely.kicks-ass.org \
    --subject='Re: [BK PATCH] Add ext3 indexed directory (htree) support' \
    /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

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).