Subject: Re: Log area on-disk for the journal
To: Bill Studenmund <wrstuden@NetBSD.org>
From: Cary G. Gray <Cary.G.Gray@wheaton.edu>
Date: 10/23/2006 07:43:45
On Sun, 22 Oct 2006, Bill Studenmund wrote:
> I think an inode is the best way for now. I don't think a jffs will have
> the same problem LFS has as files stay put on ffs once allocated. While
> the contents of the journal will change with time, its location won't.
> Thus the only metadata updates would be m & a time. Assuming we desired
> keeping them current (which I don't think we need to bother with).
In order to avoid loss of the journal, you actually need to make sure that
none of its metadata is rewritten at all--not the block containing its
inode, nor any indirect blocks. Failure during a rewrite of those leaves
you with a corrupted journal, which leaves you with a corrupted
filesystem. (My assumption here is that failure during a disk write can
leave a sector unreadable.)
It is probably necessary to special case the journal inode timestamps,
too, because writing to the log updates the journal inode timestamps,
which produces a log write, which updates the timestamps...
Using an inode to track allocation is good--it limits the amount of other
code that needs to know about the existence of the journal. But you must
be sure that nothing threatens future access to the journal. So once it
has been set up, it is probably even a good idea to stash a copy of the
inode in an area of the filesystem that does not get rewritten (except
when doing off-line operations to reconfigure the filesystem).