More external journal woes.

[Neil Brown <neilb cse unsw edu au>]

I have been playing with external journals some more and thought I
should share some experiences.

I am running 2.4.16 with the ext3 patches from Andrew Morton
and e2fsprogs 1.25

I have an ext3fs filesystem on an 8 drive RAID5 array and place the
journal on a partition of the mirrored pair that I boot off (all
drives SCSI).

I have tried pulling the power cable and seeing what happens.  I
finally got it to work (4m20s from power to prompt) but I took quite a
few tries.

Problems:
 - I have had e2fsck tell me, at least twice, 
	JFS: recovery pass 2 ended at transaction xxx, expected yyy

   where xxx was several less than yyyy.  In one case, xxx was 12, yyy
   was 14.

 - 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.

 - 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.

 - 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.

 - tune2fs will allow me to set the journal device to a device which
   does not have a valid journal.  It will then not let me remove the
   has_journal feature: 
            /dev/mda4 is not a journal device.
            Journal NOT removed

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.


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.
 I would really like a "jdev=/dev/whatever" mount option so I can be
 sure that the right device will be found
 
NeilBrown