>From: Theodore Ts'o <[EMAIL PROTECTED]>
> On Mon, Mar 06, 2006 at 09:44:47PM -0800, Elliott Mitchell wrote:
> > I was in a hurry so I might of misread the symptoms I was seeing, but it
> > sure looked like e2fsck 1.37-2sarge1 wasn't finding the journal. I didn't
> > dare try reseting the field with tune2fs for fear of losing journal
> > entries and data damage.
>
> I just built and tried e2fsprogs 1.37-2sarge1, with the external
> journal device original set up in /dev/loop0, and the filesystem in
> /dev/loop1, and then moving the journal device from /dev/loop0 to
> /dev/loop5, and indeed e2fsck was able to find it.
Okay, may of been overly cautious here. Did you try using tune2fs to
change the hint, and did it work? My concern is that the journal also has
pointers back to the filesystem(s) it acts for, and those could be
corrupted if tune2fs was unable to find the journal (at which point we're
back to e2fsck correcting that).
> > You'll note that my first message said "...and correct the superblock
> > field...", this is the main issue. Given that a filesystem with the
> > journal device hint set wrong isn't mountable and tune2fs is dangerous on
> > unclean filesystems, e2fsck MUST set the hint!
>
> Actually, it would be _nice_ if e2fsck set the hint, but it's not the
> only way to recover from the situation. You can also work around the
> problem by using the journal_dev mount option. For example, if the
> external journal device is now major 7, minor 5 (/dev/loop5, or
> 0x0705) and the filesystem is located at /dev/loop1, you can mount the
> filesystem using the command:
>
> mount -t ext3 -o journal_dev=0x0705 /dev/loop1
>
> This will update the hint in the superblock.
Did you try that? Perhaps you're looking at a different kernel version,
but in 2.6.14 no such option exists. I imagine the kernel folks would
have the attitude of leaving this for userspace as it isn't the duty of
the kernel to do such searches. This places the burdon on e2fsck, where I
think it correctly belongs.
> > Isn't `mount` supposed to be a filesystem independant utility? At which
> > point it has no business modifying flags in the superblock of an ext2
> > filesystem.
>
> No, it shouldn't be modifying flags in the superblock, but it should
> be checking to see if an external journal is required, and then
> specifying the journal_dev option if necessary. Mount does have some
> filesystem dependent code for various filesystems, in particular
> remote filesystems like nfs.
See above, no such option. To my knowledge none of that code actually
touches the filesystem device, which would be required for mount to do
such a thing. Either of these removes any such obligation.
--
(\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/)
\BS ( | [EMAIL PROTECTED] PGP 8881EF59 | ) /
\_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/
\___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
