Bug 68276 - ext3 filesystem cannot be mounted read only if external journal is destroyed
ext3 filesystem cannot be mounted read only if external journal is destroyed
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.3
All Linux
medium Severity medium
: ---
: ---
Assigned To: Stephen Tweedie
Brian Brock
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-07-08 16:16 EDT by Ben LaHaise
Modified: 2007-04-18 12:43 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-07-22 13:06:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ben LaHaise 2002-07-08 16:16:20 EDT
Failure scenario: root filesystem is ext3 with external journal.  The external
journal device is lost due to hardware failure.  The system can no longer boot
to run fsck.  It should be possible to mount the filesystem in a read-only state
to run fsck and recreate the journal internal to the filesystem.
Comment 1 Stephen Tweedie 2002-07-22 12:51:34 EDT
It's a design feature --- you *must* run fsck before you can mount a
journal-less filesystem.

"Hot" filesystem blocks can be left permanently in the journal on a busy box ---
there may never be a point at which the journal copy goes cold so we can update
the on-disk copy.  We need a fsck to have any assurance that what we're mounting
looks even remotely sane.

It still needs fixed, but I think that the _right_ fix is to have an e2fsck
option to wipe the journal and fsck the filesystem as ext2, rather than to have
the kernel deal with this.
Comment 2 Stephen Tweedie 2002-07-22 12:52:51 EDT
Incidentally, clearing the journal can already be done in this case via tune2fs
--- it's purely an admin UI enhancement to make it happen automatically or to
allow e2fsck to do it via command-line switches.
Comment 3 Ben LaHaise 2002-07-22 12:56:17 EDT
My concern is exactly what happens for the root case: fsck and other programs
are still on the filesystem and undamaged (they're not written to in normal
operation), so it should be possible to limp along in read-only mode.  Disabling
remount to rw would make sense if such a damaged filesystem had to be mounted,
but not being able to mount it at all is more of a problem.
Comment 4 Stephen Tweedie 2002-07-22 13:06:01 EDT
Yes, but that's nothing to do with the external journal --- any journal
corruption can affect the root case.

I'm still not sure what to do about that, but I think I can do a
"forever-readonly" mode which prohibits ever going read-write and which disables
all recovery for emergency use.  However, I'd want that to be a mount-time
option, and that means that initrd would need extra smarts to pass the option to
mount for the root fs.
Comment 5 Stephen Tweedie 2002-11-11 16:54:35 EST
One of the many reasons why external journals on the root dev are not supported.


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