Ext3 users - May 2001 - ext3 filesystem lost.

Hello.

We have, over the last few months, lost ext3 filesystems three times.
The whole filesystem left unusable. 

nfs-server:~# mount /dev/rd/c0d1p1 /mnt -t ext3
mount: wrong fs type, bad option, bad superblock on /dev/rd/c0d1p1,
       or too many mounted file systems

(in dmesg)
EXT3-fs: journal inode is deleted.
EXT3-fs: get root inode failed

nfs-server:~# fsck /dev/rd/c0d1p1
Parallelizing fsck version 1.18 (11-Nov-1999)
e2fsck 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
fsck.ext2: Filesystem has unsupported feature(s) while trying to open
/dev/rd/c0d1p1

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

I tried with alternate superblocks. 

This happend whilst booting our NFS-server. It hanged while umounting
its filesystems. We tried to remount the filesysem in question
read-only, but this hanged as well. When the filesystem came back up,
the filesystem was gone. The rest of the disk (the partition table) was
still healthy. 

We are running 2.2.19 with ext3-0.0.6b and the Openwall-patch[1]. Debian
potato R3. Ordered mode journaling.


Ideas?

-- 
Per Andreas Buer

[1]: This has happend before - without the openwall-patch.

Hi,

On Fri, May 11, 2001 at 04:33:56PM +0200, Per Andreas Buer
wrote:
> 
> We have, over the last few months, lost ext3 filesystems three times.
> The whole filesystem left unusable. 
> 
> nfs-server:~# mount /dev/rd/c0d1p1 /mnt -t ext3
> mount: wrong fs type, bad option, bad superblock on /dev/rd/c0d1p1,
>        or too many mounted file systems
> (in dmesg)
> EXT3-fs: journal inode is deleted.
> EXT3-fs: get root inode failed
That has the appearance of the journal inode being left unprotected
and getting accidentally deleted.
> nfs-server:~# fsck /dev/rd/c0d1p1
> Parallelizing fsck version 1.18 (11-Nov-1999)
> e2fsck 1.18, 11-Nov-1999 for EXT2 FS 0.5b, 95/08/09
> fsck.ext2: Filesystem has unsupported feature(s) while trying to open
/dev/rd/c0d1p1
This is a _really_ old e2fsck.  It doesn't understand the
ext3 recovery flags.  Any moderately recent e2fsprogs will fully
understand ext3.  There was a recovery bug in some older versions, but
the code which Ted just released:

 
ftp://download.sourceforge.net/pub/sourceforge/e2fsprogs/e2fsprogs-1.20-WIP-0510.tar.gz

doesn't have any known bugs in its ext3 handling.

You really do need to be running an ext3-aware e2fsck if you are
running the ext3 filesystem.  The old one won't know what to do to
recover the journal.  When it is live, ext3 sets compatibility flags
on the filesystem to make sure that old e2fsck versions don't
accidentally come along and wipe out the recovery information, and the
message

  fsck.ext2: Filesystem has unsupported feature(s) while trying to
open /dev/rd/c0d1p1

is what you'd expect an old e2fsck to do on encountering such a
filesystem.

Can you make progress if you use a recent e2fsck?

Btw, current e2fsprogs will automatically create journals which do not
appear in the directory hierarchy and which will therefore not be
vulnerable to being deleted accidentally.  

Cheers,
 Stephen