Bug 20129 - kernel panic after bad mount
Summary: kernel panic after bad mount
Alias: None
Product: Red Hat High Availability Server
Classification: Retired
Component: ext3   
(Show other bugs)
Version: beta
Hardware: i686 Linux
Target Milestone: ---
Assignee: Stephen Tweedie
QA Contact: Wil Harris
Depends On:
TreeView+ depends on / blocked
Reported: 2000-11-01 01:02 UTC by Hunter Matthews
Modified: 2005-10-31 22:00 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-11-01 09:53:14 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Hunter Matthews 2000-11-01 01:02:01 UTC
Following the manual instructions for converting from ext2 to ext3:

Create a journal file that is too small (IE, I mistyped the dd and got 20K,
not 20M as in the instructions)

Attempt the mount as given in the instructions. It'll fail, cuz the journal
files too small.

Remount the filesystem as ext2 to see what went wrong. Duh, 20k vs 20M.

Attempt to re-run the dd command to make the journal bigger. Recall, at
this point, it should be just another file on a plain ext2 filesystem.

Kernel panic. I can apparently reproduce, and will mail panic details if

Comment 1 Stephen Tweedie 2000-11-01 09:53:11 UTC
Yes, please post oops information.  I think I see the problem, but without the
oops trace I can't be sure that the problem I've traced is exactly the same one
that you saw.

This is a low priority problem --- the journal creation code is all going to be
moved to user space in the end anyway. However, it should be easy to fix.

Comment 2 Stephen Tweedie 2000-11-01 11:36:28 UTC
Got it --- will be fixed in a future release.  It's a trivial one-liner.

The problem was in the VFS, not in ext3: after the failed ext3 mount, ext3
correctly released all of the inodes it had established in the process of trying
to create the journal.  However, the VFS left them in cache.  On the subsequent
ext2 mount, the inode cache still contained a copy of the journal.dat inode
which had ext3 data attached, and so the second attempt to dd to journal.dat
actually ended up using the ext3 filesystem routines on an ext2 filesystem!

The fix is to call invalidate_inodes() after a failed ext3 mount to clear up the
inode cache.

Comment 3 Hunter Matthews 2000-11-01 15:56:13 UTC
Thank you. Do you still want the oops data? (I assume not...)

Comment 4 Stephen Tweedie 2000-11-01 16:15:23 UTC
If you have it to hand, it will let me confirm for sure that it's the same
problem.  If not, I'll just assume that it is and leave it closed.  So sure,
send it if you have it but don't go out of your way to reproduce it if you

Note You need to log in before you can comment on or make changes to this bug.