[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: root fs type in fstab

On Thu, Jan 18, 2001 at 03:10:04PM -0700, Andreas Dilger wrote:
> The 0117 version is definitely the one to use.  Observant people will
> see that it has a "journal device"

I did notice ~drooling at visions of the log on NVRAM type devices~
as I was trawling through the source code.

> option, but this totally doesn't
> work, so don't even try (no kernel support, no e2fsck support).

And here I was thinking I missed the "alternate device support"
note on one of the recent ext3 release notices.  :-)

> The
> only thing you can do is create a journal device, and run e2fsck which
> will complain it is unsupported and remove it.

There is a bug with the new options.  If you supply a "-j" but no
"-J..." it will complain.  I believe this is because of:

        if (!open_flag && !l_flag)

The manual page also does not state that "size" is in terms of MBs.

> Yes.  For journals created on a mounted filesystem, you will have a
> regular file for the journal (with the immutable attribute set).  For
> journals created on an unmounted filesystem, you will use a reserved
> inode, so no danger of backup/restore or user-deletion problems.

Actually, it used a reserved inode even though the filesystem was
mounted.  I can tell you why.  I am creating the system with the ext3
root filesystem via kickstart.  Kickstart gives you a hook after every-
thing is loaded to run some customization shell script.  At that point,
the filesystem is mounted but /etc/mtab is not populated.  I guess my
scripts could mock up an /etc/mtab so that tune2fs understands it
really is mounted.

> It's not a bug I'm aware of.  It may have something to do with interaction
> between the kernel creating the journal and e2fsck.  If you are not
> using 0.0.5e, there was an issue with how the journal superblock was
> created, so it _could_ cause segfaults in e2fsck.

0.0.5d still.  It is still there with the 0117 e2fsprogs snapshot.

> However, it is still
> worthwhile to figure out where e2fsck is segfaulting (before you upgrade
> ext3 or e2fsck),

I guess what puzzles me is why is the journal being replayed on that
first boot?  It does seem as though it is corrupting the superblock
and it is the corrupt superblock that is causing the remaining failures
including the SIGSEGV.

Is the reason for the journal replay not really the issue to track down?
I am guessing if the journal replay is not done (why should it be --
it's a brand new ext3 filesystem afterall) then the superblock wouldn't
get corrupted and the rest of the problems would go away, no?

And then maybe the replay is happening because of the bug in 0.0.5d.

I should see about upgrading to 0.0.5e.

Oh... the tune2fs option for creating the journal is sweet!!  In
my short trawl through the code it looked like mk2efs was capable of
creating filesystems with journals on them much like a "mk2efs +
tunefs -j" would produce.  Am I correct?  Would it not be correct to
hack together an mkfs.ext3 by doing some argv[0] checking in mk2efs


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]