[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]