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