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

Re: Ext3 and external journals...

On Nov 08, 2001  11:45 -0500, Theodore Tso wrote:
> On Mon, Nov 05, 2001 at 11:17:58AM -0700, Andreas Dilger wrote:
> > Note that external journals aren't really supported fully.  The e2fsck
> > code does not yet work when e2fsck'ing a journal device directly.  What
> > _should_ happen is that it goes out and e2fsck's all of the users of
> > the journal, and any devices which can't be found (by UUID) have their
> > journal data written to a file, and when they are e2fsck'd they first
> > check for this journal file to recover their journal transactions.
> > 
> > Granted that we are nowhere close to supporting shared external journals
> > yet, but the basic support could be added (i.e. fsck'ing the journal
> > device instead of the filesystem itself).
> We really should make a distinction between shared journals and
> external 1:1 journal.  The latter should work, except that it hasn't
> received a lot of testing.  Shared journals were explicitly not
> supported, and there's a bunch of work both in user space and kernel
> space left to be done.   

Agree fully.

> Changing things so that you run fsck on the journal device instead of
> the filesystem is something we could easily do even before we have
> full shared journal support, and it probably is a good idea for us to
> support that and document that as the way to do external journals
> before we start encouraging people to play with the code, just because
> it means we won't have to deal with the support headache of getting
> people to change their /etc/fstab files when we do finally get around
> to adding support for shared journals.

Yes, I think so as well.  The current situation would need that the
external journal be added with "noauto" as a mount option, and
in /etc/fstab so that it is checked before any client filesystem.

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

Cheers, Andreas
Andreas Dilger

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