On Tue, Mar 07, 2006 at 01:39:58PM -0800, Elliott Mitchell wrote:
> > 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).
No, I didn't use tune2fs to change the hint; it's not necessary.
E2fsck simply used the uuid in the filesystem to find the external
journal, using the blkid library. Tune2fs also uses the blkid library
to find the journal, so removing the journal and adding it back again
would have worked, but what I was interesting in disproving was your
contention that e2fsck can't find the journal. That's not true.
E2fsck finds the jouranl just fine. It just doesn't update the hint,
so that the in-kernel mount code can't find the journal.
In terms of external journal containing pointers back to the
filesystems, it does, but only via the filesystem UUID that it
supports, and so that works just fine.
> > 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.
Yes, I did try it, and it did work. You're right that it is a
relatively new feature; it showed up in 2.6.16-rc1, and was committed
into the git tree on January 8, 2006. Ages ago as far as kernel
development is concerned! :-)
The attitude is indeed to leave this for userspace for doing such
searches; that's why what is specified is the device number. The
correct tool for doing the searches is the blkid library, which is
what e2fsck and tune2fs uses, and arguably mount should be enhanced to
use the blkid library as well for this case. Failing that, this tiny
bit of shell script would have done the trick for you (assuming you
were using a recent kernel, of course):
# Device to mount
DEV=/dev/loop1
UUID=`dumpe2fs $DEV 2>/dev/null | awk '/^Journal UUID/{print $3}'`
JDEV=`blkid -t UUID=$UUID | awk -F: '{print $1}'`
DEVNUM=0x`stat -c %02t $JDEV``stat -c %02T $JDEV`
mount -o journal_dev=$DEVNUM $DEV
The problem with placing the burden solely on e2fsck is that if we
don't need to replay the journal (because the filesystem was unmounted
cleanly) e2fsck won't even attempt to find the journal, so it won't
know that the hint was incorrect. And what if e2fsck wasn't run for
some reason? The hint is never guaranteed to be correct, and in some
system setups might change at every boot. And requiring that e2fsck
be run before you can mount the filesystem is really broken.
Putting the burden on the userspace mount program is really the right
place from an architectural design point of view. Still, I'll add
something to e2fsck in the short term, since getting something into
will be slower, but it's really a short-term workaround and not the
right long-term solution.
- Ted
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
