Hi,
I've tried to test noload/norecovery option of ext3 and I've found it
simply does not work. The filesystem does not even mount. There are two
problems:
1) the code checking for NOLOAD in ext3_fill_super is simply wrong
and ends up failing the mount whenever NOLOAD is set with a message
"ext3: No journal on filesystem on <dev>"
2) if one fixes the check, we end up oopsing a few lines below when
calling journal_check_available_features() with journal == NULL.
Given that nobody used the option (OK, some googling shows that somebody
tried to use it in *2.4.9* kernel and it didn't work even there - Stephen
Tweedie comments that it's an obsolete option meant for use during fs
development) and seeing how badly corrupted the filesystem is when you
don't replay the journal, I'd just remove the option. Any opinions?
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR
Jan Kara wrote:
> Hi,
>
> I've tried to test noload/norecovery option of ext3 and I've found it
> simply does not work. The filesystem does not even mount. There are two
> problems:
> 1) the code checking for NOLOAD in ext3_fill_super is simply wrong
> and ends up failing the mount whenever NOLOAD is set with a message
> "ext3: No journal on filesystem on <dev>"
> 2) if one fixes the check, we end up oopsing a few lines below when
> calling journal_check_available_features() with journal == NULL.
>
> Given that nobody used the option (OK, some googling shows that somebody
> tried to use it in *2.4.9* kernel and it didn't work even there - Stephen
> Tweedie comments that it's an obsolete option meant for use during fs
> development) and seeing how badly corrupted the filesystem is when you
> don't replay the journal, I'd just remove the option. Any opinions?
>
> Honza
Oh, sigh. Sorry, didn't actually, er, test it, since I was just adding
an alias for the option... bleah.
I think we should fix it; there are cases when you may want to mount that
way, I think - for example, otherwise there is no way at all to mount
a block device which is marked readonly...
-Eric
On 2009-11-20, at 07:46, Eric Sandeen wrote:
> Jan Kara wrote:
>> I've tried to test noload/norecovery option of ext3 and I've found
>> it simply does not work. The filesystem does not even mount.
>> Given that nobody used the option (OK, some googling shows that
>> somebody tried to use it in *2.4.9* kernel and it didn't work even
>> there - Stephen Tweedie comments that it's an obsolete option meant
>> for use during fs development) and seeing how badly corrupted the
>> filesystem is when you don't replay the journal, I'd just remove
>> the option. Any opinions?
>
> Oh, sigh. Sorry, didn't actually, er, test it, since I was just
> adding an alias for the option... bleah.
>
> I think we should fix it; there are cases when you may want to mount
> that way, I think - for example, otherwise there is no way at all to
> mounta block device which is marked readonly...
Won't this require implementing "no journal" mode for ext3? Seems
like a lot of effort, when ext4 does the same thing (i.e. they could
just mount the filesystem "-t ext4 -o norecovery" if they really,
really need to do that).
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
Andreas Dilger wrote:
> On 2009-11-20, at 07:46, Eric Sandeen wrote:
>> Jan Kara wrote:
>>> I've tried to test noload/norecovery option of ext3 and I've found
>>> it simply does not work. The filesystem does not even mount.
>
>>> Given that nobody used the option (OK, some googling shows that
>>> somebody tried to use it in *2.4.9* kernel and it didn't work even
>>> there - Stephen Tweedie comments that it's an obsolete option meant
>>> for use during fs development) and seeing how badly corrupted the
>>> filesystem is when you don't replay the journal, I'd just remove the
>>> option. Any opinions?
>>
>> Oh, sigh. Sorry, didn't actually, er, test it, since I was just
>> adding an alias for the option... bleah.
>>
>> I think we should fix it; there are cases when you may want to mount
>> that way, I think - for example, otherwise there is no way at all to
>> mounta block device which is marked readonly...
>
>
> Won't this require implementing "no journal" mode for ext3? Seems like
> a lot of effort, when ext4 does the same thing (i.e. they could just
> mount the filesystem "-t ext4 -o norecovery" if they really, really need
> to do that).
I don't see why it would need nojournal mode; you'd have to:
mount -o ro,norecovery
anyway, and if it's ro the journal should be non-operational anyway right?
(Jan, did you mount -o norecovery or -o ro,norecovery in your tests?)
-Eric
> Cheers, Andreas
> --
> Andreas Dilger
> Sr. Staff Engineer, Lustre Group
> Sun Microsystems of Canada, Inc.
>
On Fri 20-11-09 11:56:15, Eric Sandeen wrote:
> Andreas Dilger wrote:
> > On 2009-11-20, at 07:46, Eric Sandeen wrote:
> >> Jan Kara wrote:
> >>> I've tried to test noload/norecovery option of ext3 and I've found
> >>> it simply does not work. The filesystem does not even mount.
> >
> >>> Given that nobody used the option (OK, some googling shows that
> >>> somebody tried to use it in *2.4.9* kernel and it didn't work even
> >>> there - Stephen Tweedie comments that it's an obsolete option meant
> >>> for use during fs development) and seeing how badly corrupted the
> >>> filesystem is when you don't replay the journal, I'd just remove the
> >>> option. Any opinions?
> >>
> >> Oh, sigh. Sorry, didn't actually, er, test it, since I was just
> >> adding an alias for the option... bleah.
> >>
> >> I think we should fix it; there are cases when you may want to mount
> >> that way, I think - for example, otherwise there is no way at all to
> >> mounta block device which is marked readonly...
> >
> >
> > Won't this require implementing "no journal" mode for ext3? Seems like
> > a lot of effort, when ext4 does the same thing (i.e. they could just
> > mount the filesystem "-t ext4 -o norecovery" if they really, really need
> > to do that).
>
> I don't see why it would need nojournal mode; you'd have to:
>
> mount -o ro,norecovery
>
> anyway, and if it's ro the journal should be non-operational anyway right?
>
> (Jan, did you mount -o norecovery or -o ro,norecovery in your tests?)
Actually, just -o norecovery but after the oops I've looked at the code
and concluded that -o ro won't help the oops anyway... But yes, fixing the
code in read-only mode should be possible.
Honza
--
Jan Kara <[email protected]>
SUSE Labs, CR