In message <20030818181354.GC10270@think>, "Theodore Ts'o" writes: > On Mon, Aug 18, 2003 at 12:39:46PM -0400, Erez Zadok wrote: [...] > > Now I was able to start "e2fsck -b 71663616 -B 4096 /dev/md0". It's been > > running for a couple of hours already. Of course, it's discovering all > > sorts of wonderful new events and spewing messages I've never even seen > > before. 1/2 a :-) 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. [...] > You can use debugfs's feature command to turn off the has_journal bit > as follows: > > debugfs -w /dev/hdaXX > debugfs: features ^has_journal > debugfs: features ^needs_recovery > debugfs: quit Ted, I tried it: ------------------------------------------------------------------------------ # debugfs -w /dev/loop1 debugfs 1.32 (09-Nov-2002) /dev/loop1: Can't read an inode bitmap while reading inode bitmap debugfs: features ^has_journal features: Filesystem not open debugfs: quit ------------------------------------------------------------------------------ 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: ------------------------------------------------------------------------------ # ~/e2fsprogs-1.34/debugfs/debugfs -c -w /dev/loop1 debugfs 1.34 (25-Jul-2003) /dev/loop1: catastrophic mode - not reading inode or group bitmaps debugfs: features ^has_journal Filesystem features: filetype sparse_super large_file debugfs: features ^needs_recovery Filesystem features: filetype sparse_super large_file debugfs: quit # tune2fs -l /dev/loop1 | grep -i filesystem Filesystem volume name: <none> Filesystem UUID: a1c20f0a-b85d-415e-bb39-0ab111dd9e58 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: filetype sparse_super large_file Filesystem state: clean with errors Filesystem OS type: Linux # e2fsck -n /dev/loop1 e2fsck 1.32 (09-Nov-2002) Group descriptors look bad... trying backup blocks... e2fsck: Invalid argument while checking ext3 journal for /dev/loop1 # 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 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: ------------------------------------------------------------------------------ # ~/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 ------------------------------------------------------------------------------ Suggestions for what to do next (including "just give up, dude" :-) are welcome. Thanks, Erez. _______________________________________________ Ext3-users@redhat.com https://www.redhat.com/mailman/listinfo/ext3-users
