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

Re: Ext3 and external journals...



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.

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

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.

						- Ted





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