Ext3 users - Dec 2001 - help with recovering inode

Hi list,

here's what just happend:

I rebooted my 2.4.15 running machine with SysRq + s u b to boot into 2.4.17pre8.
All went fine, fsck found no errors. Upon starting X i found out that my .opera
directory went fubar in some way. Stracing ls shows that it gets an EIO trying
to stat it. Looking at it with debugfs (and learning fs internals on the fly)
shows that inode of that directory only has ctime, mtime and atime set, all
other values are zero. With the mi command i managed to make it back to
directory, now i only have to find out which blocks this inode pointed to before
it went fubar. Any idea on how to do that?

I really want to know what happened really with this inode ...

Background:

HW: old faithful p200, single ide disks, partitions hda1 on /boot and hda3 on /,
both ext3, redhat 7.2.
~/.opera is a symlink pointing to /boot/gold/.opera (/boot was on a raid1 once
in the history of that box, with gold dir for 'important' stuff like
browser settings, bookmarks and mail).
What was happenning with hda1 before reboot:
I tried to copy the new bzimage on it, but found out it was full. So moved my
mail to ~/Mail (maildir, ~15k small files) on hda3 and then copied bzimage to
/boot. Edited /boot/grub/grub.conf and then SysRq sub. When the box came up,
.opera in /boot/grub was nonexistant.

the remains of it:

debugfs:  stat .opera
Inode: 7745   Type: regular    Mode:  0000   Flags: 0x0   Generation: 0
User:     0   Group:     0   Size: 0
File ACL: 0    Directory ACL: 0
Links: 0   Blockcount: 0
Fragment:  Address: 0    Number: 0    Size: 0
ctime: 0x3c168d6f -- Tue Dec 11 23:49:19 2001
atime: 0x3c168d9d -- Tue Dec 11 23:50:05 2001
mtime: 0x3c168d6f -- Tue Dec 11 23:49:19 2001
BLOCKS:

debugfs:  mi .opera
                          Mode    [0100000] 
                       User ID    [0] 
                      Group ID    [0] 
                          Size    [0] 
                 Creation time    [1008110959] 
             Modification time    [1008110959] 
                   Access time    [1008111005] 
                 Deletion time    [0] 
                    Link count    [0] 
                   Block count    [0] 
                    File flags    [0x0] 
                    Generation    [0x0] 
                      File acl    [0] 
           High 32bits of size    [0] 
              Fragment address    [0] 
               Fragment number    [0] 
                 Fragment size    [0] 
               Direct Block #0    [0] 
               Direct Block #1    [0] 
               Direct Block #2    [0] 
               Direct Block #3    [0] 
               Direct Block #4    [0] 
               Direct Block #5    [0] 
               Direct Block #6    [0] 
               Direct Block #7    [0] 
               Direct Block #8    [0] 
               Direct Block #9    [0] 
              Direct Block #10    [0] 
              Direct Block #11    [0] 
                Indirect Block    [0] 
         Double Indirect Block    [0] 
         Triple Indirect Block    [0] 

I set mode back to 040755, but how do i find out the Direct Block #0 number?

-- 


Jure Pecar

Jure Pecar wrote:
> 
> Hi list,
> 
> here's what just happend:
> 
> I rebooted my 2.4.15 running machine with SysRq + s u b to boot into
2.4.17pre8.
> ...
2.4.15 was not a good kernel - it had the forget-to-flush-inodes-on-unmount
bug.  However I never had any problems with it - I think ext3 was immune
to the bug because it tends to take care of itself and doesn't use the
core kernel for lots of write things.

So...  I can't ofer a believable explanation of what happened to your
inode.
> I set mode back to 040755, but how do i find out the Direct Block #0
number?
hmm.  If you can remember the names of the files in that directory,
you can search the underlying device for the filenames. That will
take you to a block which you can recognise as the directory
block.

The attached program may help.

	bgrep /dev/hda1 68 64 6c 6c 6f

http://freshmeat.net/projects/lde/ may be good, but the homepage
seems to be offline.

Andrew Morton wrote:
> 
> The attached program may help.
Doh.