On Tue, Aug 19, 2003 at 01:27:43PM -0400, Erez Zadok wrote: > As a quick reminder: I had run "mke2fs -S" on a copy of this corrupt f/s, > specifically wiping the journal file, superblocks, and group descriptors. > Then ran fsck for hours. It found tons of errors, and only recovered a > small portion of data. I don't know how much that data loss was exacerbated > (if any), but the -S flag. I doubt it was exacerbated by the lack of the -S flag. > Alas, I cannot open the f/s for read/write, and catastrophic mode won't help > me in its current form. So I'm in need of your proposed mods to debugfs. > Could you get me a modified version, patches to one, or just point me at > where in the source could I try to hack this myself? > > BTW, the debugfs error message is not terribly useful or descriptive. What > does it _really_ mean? > > In the mean time, I've hacked a version of debugfs (from 1.34) and commented > out the check for the -c and -w options, allowing read/write with -c. This > is what happened: The patches to debugfs is to remove the read/write check to -c, and then auditing all of debugfs's code paths to make sure that the bitmaps are not initialized (for in catastrophic mode the bitmaps are not read in if they are buggy), that debugfs won't crash or do something evil when in read/write mode. So your hack is the first part of the patch. I haven't had a chance to do the audit of debugfs to make sure making that change is safe, though. (It _probably_ wouldn't cause any data loss, but some of debugfs's read/write commands might core dump). > I don't understand why after turning off the has_journal bit, I'm still > getting errors related to the journal. > > My guess is that e2fsck checks for the journal inode no matter what, so I > need to unlink it. So next I tried more desperate measures: Yup, e2fsck checks to see if the standard journal inode is there. > ------------------------------------------------------------------------------ > # ~/e2fsprogs-1.34/debugfs/debugfs -c -w -b 4096 -s 20480000 /dev/loop1 > debugfs 1.34 (25-Jul-2003) > /dev/loop1: catastrophic mode - not reading inode or group bitmaps > debugfs: stat <8> > stat: Invalid argument while reading inode 8 > debugfs: features > Filesystem features: filetype sparse_super large_file > debugfs: clri <8> > clri: Invalid argument while reading inode 8 > debugfs: freei <8> > freei: Filesystem bitmaps not loaded > debugfs: quit > > # e2fsck -n -B 4096 -b 20480000 /dev/loop1 > e2fsck 1.32 (09-Nov-2002) > e2fsck: Invalid argument while checking ext3 journal for /dev/loop1 > ------------------------------------------------------------------------------ I'll have to take a look at the output of dumpe2fs, but if clri failed, that probably means that block group descriptors that tell us where to find the first part of the inode table was corrupted. (This is one of the things which mke2fs -S fixes). - Ted _______________________________________________ Ext3-users@redhat.com https://www.redhat.com/mailman/listinfo/ext3-users
