Ext3 users - Jul 2001 - My fault (not ext3's!) and kernel panic on 2.4.7 .

Hello all.
I was playing with tune2fs to see how large the .journal file should
be on a 17G partition with 512M ram (it's 32M, by the way).
I am using plain 2.4.7 with ext3-2.4-0.9.4-247,
compiled with gcc-2.96-85 on a RH7.1 distribution with the relevant
changes, i.e. e2fsprogs-1.22-1, mount-2.11g-4 and
util-linux-2.11f-3 taken from rawhide.
I don't have any ext3 statement in /etc/fstab, all is ext2.
The 0.9.4 patch has been corrected ->
Please, in fs/jbd/journal.c replace `SLAB_POISON' with zero.

Unwisely I deleted the .journal file, since I never mounted / as ext3.

On next boot the box panicked in journal.c (sorry, do not have
the relevant info).

To correct the situation I simply booted with 2.4.5 without the
ext3 patches. It corrected the error reverting to ext2:

Jul 29 13:11:36 uno fsck: /dev/hda4: Superblock has a bad ext3 journal
(inode 20).
Jul 29 13:12:37 uno xinetd[513]: Started working: 0 available services
Jul 29 13:11:36 uno fsck: CLEARED.
Jul 29 13:11:36 uno fsck: *** ext3 journal has been deleted - filesystem
is now ext2 only ***
Jul 29 13:11:36 uno fsck: /dev/hda4 was not cleanly unmounted, check
forced.
Jul 29 13:11:36 uno fsck: /dev/hda4: 236046/2265408 files (2.1%
non-contiguous), 1415789/4521984 blocks
...

I was certainly wrong deleting the .journal without changing the
parameters of the ext3 filesystem. However IMHO the kernel should be
able to correct the situation and revert to ext2 without intervention
in this case. Rebuilding the journal file is a matter of 1" (at least
on this mighty machine...).

Any comment? Thanks for the hard work on the new filesystem. I think
I'll move shortly my partitions on ext3.

The relevant harware:

AMD Athlon 1.2 GHz, 512M ram,
hda: QUANTUM FIREBALLP LM20.5, ATA DISK drive
hdc: IBM-DJNA-371350, ATA DISK drive
hda: 40132503 sectors (20548 MB) w/1900KiB Cache, CHS=2498/255/63,
UDMA(66)
hdc: 26520480 sectors (13578 MB) w/1966KiB Cache, CHS=26310/16/63,
UDMA(33)

Sincerely, Nicola Fabiano

On Sun, Jul 29, 2001 at 06:22:17PM +0200, beevis@libero.it
wrote:
> Unwisely I deleted the .journal file, since I never mounted / as ext3.
I assume the ext3 filesystem was created using old e2fsprogs tools;
the new versions will create it as a hidden file that doesn't appear
in the namespace, as long as the filesystem is unmounted --- and even
if it is mounted, the .journal file is created with the immutable flag
set.
> Jul 29 13:11:36 uno fsck: /dev/hda4: Superblock has a bad ext3 journal
> (inode 20).
> Jul 29 13:12:37 uno xinetd[513]: Started working: 0 available services
> Jul 29 13:11:36 uno fsck: CLEARED.
> Jul 29 13:11:36 uno fsck: *** ext3 journal has been deleted - filesystem
> is now ext2 only ***
> Jul 29 13:11:36 uno fsck: /dev/hda4 was not cleanly unmounted, check
> forced.
> Jul 29 13:11:36 uno fsck: /dev/hda4: 236046/2265408 files (2.1%
> non-contiguous), 1415789/4521984 blocks
> ...
> 
> I was certainly wrong deleting the .journal without changing the
> parameters of the ext3 filesystem. However IMHO the kernel should be
> able to correct the situation and revert to ext2 without intervention
> in this case. Rebuilding the journal file is a matter of 1" (at least
> on this mighty machine...).
The kernel wouldn't care if you just deleted the .journal file, as
long as you were mounting using ext2 and the NEEDS_RECOVERY flag
wasn't set.

What happened here was that fsck noticed that the filesystem was
inconsistent, and therefore finished cleaning up the filesystem.  No
big deal; the right thing happened.

							- Ted