On Tue, Dec 11, 2001 at 01:44:50PM +1100, Neil Brown
wrote:>
> - After the e2fsck fails, "tune2fs -l" on the journal device
shows
> much the same superblock as on the main device. Normally it
> fails to find a superblock on the journal device.
Use dumpe2fs, not "tune2fs -l". Tune2fs doesn't know about the
special superblocks used by the journal device. The fact that
"tune2fs -l" works after e2fsck fails is definitely very weird. If
you could send us the output of dumpe2fs on the journal device before
and after the e2fsck failure, that would be very interesting.
> - e2fsck will not progress if the journal device is bad (e.g. when the
> super block is wrong as above). I cannot say 'Ignore the journal
> and fsck'. It just stops. Even after I turn off has_journal (see
> below), it still won't let me fsck because there is a uuid and a
> journal device set in the superblock. I now have a hacked e2fsck
> which ignores the journal.
This was using e2fsprogs 1.25? I just tried creating a filesystem
with an external journal device, then used debugfs to zip the
has_journal flag, and then ran e2fsck. It asked the question:
"Superblock doesn't have has_journal flag, but has ext3 journal inode.
Clear<y>?". So it works for me....
> - tune2fs doesn't let me turn off has_journal if needs_recovery is
> set, and doesn't let me turn off needs_recovery. Fortunately
> debugfs does. However it doesn't remove the journal uuid, or the
> journal device number from the superblock when I do turn of
> has_journal. Nor does there seem to be a debugfs command to allow
> this. Hence the need for the hacked e2fsck.
The reason behind this is that simply junking the journal is a very
hazardous operation. The filesystem is likely to be quite badly
damaged if you just blithly throw away the journal before it is run.
Granted, we need some kind of recovery if the journal device is
completely trashed, but making it trivially easy for the user to shoot
themself in the foot isn't such a great idea, either?
> - tune2fs will allow me to set the journal device to a device which
> does not have a valid journal.
Again, which version of e2fsprogs are you using? Tune2fs should *NOT*
be letting you set the journal device to a device which does not have
a valid journal:
# tune2fs -J device=/dev/ram /tmp/foo.img
tune2fs 1.25 (20-Sep-2001)
tune2fs: Bad magic number in super-block
while trying to open journal on /dev/ram
> Observations:
> If I set the fsck pass number in /etc/fstab to 0, so that fsck
> doesn't run, the the kernel seems to recover the journal
> successfully.
It seems **very** wierd that the kernel is able to recover the
journal, but e2fsck is failing. I haven't done testing of external
journal very recently, but a few months ago, it was definitely
working. I'll have to give that a try, although at the moment I'm on
the road so I don't easily have access to hardware that would really
allow me to play with external journals.
> Comments:
> with the increasing lack of stability of device numbers in linux, I
> don't feel at all comfortable about ext3 using a device number to
> find the journal device.
> I gather that there is a plan to allow the journal device to be
> "mounted" before the ext3 filesystems so they can then find
their
> journal by UUID, but that seems a little way off.
E2fsprogs will look up the journal device by UUID. The long-range
plan is to only support external journal devices via e2fsck, and not
via the in-kernel mount scheme, and to not support use of an external
journal for the root filesystem. (There are a bunch of reasons why
that would get horribly complicated, mainly having to do with how you
recover if the journal device is temporarily off-line, so the plan was
to simply not to support external journals for the root filesystem.)
- Ted