Re: (reiserfs) Re: New Linux 2.5 - 2.6 TODO (Alan Cox suggests delaying reiserfs integration)

From: Andreas Dilger (adilger@turbolabs.com)
Date: Mon Jun 05 2000 - 10:18:30 EST


Chris Mason writes:
> It seems that Stephen started out with the goal of making a generic, easy
> to use layer for any FS, with the best interests of the linux kernel in
> mind. I wrote something just for us, because I wanted a challenge. Look
> through the ext3 code and the reiserfs journal.c, and it will be clear
> Stephen knew what he was doing from the start, and I learned as I went
> along.

One of the very important features of Stephen's JFS code is that it allows
the nesting of transactions. This allows our filesystem code to start a
transaction in our code, update several files within that transaction,
and then finish the transaction again in our code. The JFS journal_start()
and journal_stop() functions are smart enough that if they try to start a
new transaction in a process that already has a running transaction, they
"piggy back" on the running transaction. This is definitely not possible
in the current ReiserFS journalling code.

Actually, the JFS implementation (which is not the same as ext3 - ext3 is
only a user of JFS) could _almost_ be moved up into the VFS and allow
journalling for all block-based filesystems. Not quite, but almost. I
suspect that it would need some rework to handle extent-based filesystems
like ReiserFS.

Unfortunately, it may be that XFS and IBM JFS will have their own journalling
requirements that do not mesh with Stephen's JFS for various reasons (one
being simply code portability between their native OS and Linux). I think
that Stephen's JFS is closely modelled after XFS in the sense that the
journal doesn't know anything about the filesystem at all - it is simply a
repository of disk blocks in a specific order.

Chris - at some point, does the ReiserFS journal boil down to the same idea -
a series of disk blocks written in a specific order? I haven't studied the
internals of ReiserFS too closely, but in order to get any kind of performance
(which it obviously does), it still needs to do large block-based I/O to
the disk even if it allows handling of small fragments/extents within each
block. If that is the case, it may be _possible_ to use JFS at a low level
within ReiserFS.

Cheers, Andreas

-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:21 EST