Recover original superblock on corrupted filesystem?

[bloch at verdurin.com]

On Tue, 25 Oct 2005, bloch at verdurin.com wrote:

> On Tue, 25 Oct 2005, Stephen C. Tweedie wrote:
> 
> > Hi,
> > 
> > On Fri, 2005-10-21 at 15:51 +0100, bloch at verdurin.com wrote:
> > 
> > > It appears the original superblock is corrupted too, as it has an inode
> > > count of 0.  When I start fsck with -b 32760, it uses the alternate
> > > superblock and proceeds.  However, it restarts from the beginning a
> > > couple of times and after the second restart it doesn't use the
> > > alternate superblock, stopping instead as it can't find the original
> > > one.
> > 
> > Do you have a log of the fsck output, and which e2fsprogs version is
> > this?  Sounds like it may be an e2fsck bug if we don't honour the backup
> > superblock flag on subsequent passes.
> > 
> 
> I do have a log, yes.  It's rather large...
> 
> It's version 1.38
> 
> > > Is there a way around this, such as using one of the alternate
> > > superblocks to replace the broken one
> > 
> > Yes, "dd" of the appropriate block should work... but do this with
> > extreme care, as getting it slightly wrong will cause major havoc.
> > 
> > "debugfs" may be a better bet.  
> > 
> > 	# debugfs -w -b$BLOCKSIZE -s$SUPERBLOCK /dev/$DEV
> > 
> > will tell debugfs to read the specified superblock.  If you dirty the
> > superblock (eg. with the "dirty" command) then quit, it will write back
> > the backup superblock to the home location too.
> > 
> 

As an update to this, the problem seems to have re-occurred.  Here are
the relevant error messages:

EXT3-fs error (device sdb1): ext3_new_block: Allocating block in system
zone - block = 41484288
Aborting journal on device sdb1.
EXT3-fs error (device sdb1) in ext3_new_block: Journal has aborted
ext3_abort called.
EXT3-fs error (device sdb1): ext3_journal_start_sb: Detected aborted
journal
Remounting filesystem read-only
EXT3-fs error (device sdb1) in ext3_reserve_inode_write: Journal has
aborted
__journal_remove_journal_head: freeing b_committed_data

Is there anything you can suggest to look at before I run fsck on this?

Thanks,
Adam