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

Re: Ext3 and external journals...

On Nov 09, 2001  11:51 -0500, Theodore Tso wrote:
> On Thu, Nov 08, 2001 at 02:55:25PM -0700, Andreas Dilger wrote:
> > Hmm, a potential problem is that root must be mounted r/w in case
> > the journal device needs to dump the contents for an unknown client
> > filesystem.  
> One of the other questions is what to do if there isn't enough space
> on the root filesystem for the journal to be dumped.  There may not be
> a good answer to this question, but it is something we need to think
> about.  In the case of a double-fault (disk has gone off-line, and no
> space in the root filesystem to save that part of the shared-journal
> device relating to the filesystems on that disk that has gone
> off-line), it may be that aborting the boot process and letting an
> operating sort out the pieces is the best we can do.

Yes, this is probably enough for the majority of cases.  The alternative
would be to fail mounts which try to use that journal, but I don't know
which is better.  Maybe both.

> >Having the journal device in passno=2 means it could
> > be recovered out-of-order with the client filesystem because of
> > device-sharing issues.  An easy solution is to put users of journal
> > devices into passno=3, but it may be desirable to also have some
> > safeguards in case people don't do this correctly (maybe have fsck
> > or fsck.ext3 smart enough to block attempts to fsck the client before
> > a shared journal).
> Given how many support questions we've been getting on ext3-users, and
> how I've been harping on people to worry about usability issues in
> Linux, right now I'm very tempted to solve this problem by putting in
> a special-case hack into fsck.  Namely, we tell users to set the
> filesystem type of the shared journal in /etc/fstab to be something
> like "jbd", and then special case fsck's handling so that all
> jbd-typed filesystems are checked first.

Yes, we definitely want them in /etc/fstab as type jbd.  Normally, if
we enforce mount ordering on jbd and client-ext3 filesystems it would
be OK for fsck, but fsck has the possibility to re-order devices if
there are disk-device conflicts.  What might be the most clever setup
is to add jbd client UUID checking as added dependencies for fsck.
With libblkid we already get the client filesystem UUIDs for free, and
all we need to do is add "if you are fsck'ing jbd device X, then you
can't yet fsck ext3 devices Y,Z".  This still allows parallel fsck to
work, because we have proper dependencies.

> As far as marking jbd filesystems as "noauto", eventually we really do
> want the jbd filesystems to be mounted, so that we have protections
> against people accidentally running mke2fs on the shared journal
> device.  Havingg the shared journal be mountable also provides a
> convenient place for a synthentic filesystem which could be queried to
> obtain various bits of diagnositic information about how much of the
> journal has been used, when the last time the log has been truncated,
> what filesystems are currently using the journal, etc.  It also has
> the nice feature that if we change the rules so that the external
> journal must always be mounted first, then we don't need code in the
> kernel to search for the external journal device by UUID.

You're preaching to the choir on this one.  Remember that I've already
implemented the pseudo-fs mounting for jbd devices for all of the above
reasons.  All I'm suggesting with "noauto" is a temporary state to allow
e2fsck to work until the pseudo-fs code is incorporated into ext3/jbd.
This allows us to put in the jbd line into /etc/fstab for external
journals without requiring jbd pseudo-fs support to be available.

Cheers, Andreas
Andreas Dilger

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