On Mon, 5 Jun 2000, Andreas Dilger wrote:
> 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.
>
The only thing reiserfs needs to support this is some way of communicating
the current process is already in a transaction. *But*, the nesting could
only be legal if the parent transaction has reserved enough blocks for the
nested transaction to complete as well. I'll have to check the rules that
ext3 uses in allowing the nesting.
> 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.
>
Quick clarification, reiserfs doesn't use extents yet...
> 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?
Yes, ext3's jfs and reiserfs have the same fundamental ideas.
block based write ahead logging. With slight modifications to the jfs,
wandering logs could even fit in.
The ext3 jfs might also need small changes to wok cleanly with any
allocate on flush systems (XFS, reiserfs soon).
> 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.
>
Very possible, regardless of how you log the data, the api steps need to
make it all work are almost the same. From what I've read about xfs, it
could fit into the ext3 jfs as well. I'm assuming GFS will need the most
complicated journal layer...
-chris
-
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