On Mon, 5 Jun 2000, Andreas Dilger wrote:
> Chris Mason writes:
> > 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.
>
> It is mostly true that ext3 transactions need enough space reserved at the
> parent transaction for all nested transactions to complete. However, some
> transactions like write and truncate may be split into multiple transactions
> if they grow too large. This problem will disappear when ext3 moves to
> metadata-only journalling.
>
Ok, I have to allow the transaction to end inside a write and truncate as
well. Even with metadata only logging, it is much easier to allow
multi-transaction truncate/write than to force the whole thing into a
single transaction. It is also more fair
> > 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.
>
> What are wandering logs, if I might ask?
>
This is an idea from Hans. Instead of having a dedicated logging area on
the disk, any block can be a log block. Unlike ext2, reiserfs metadata
can be anywhere on the disk. Placement of these tree nodes is critical to
performance, and the wandering logs idea allows you to log the block by
simply writing it to a new (better) location. So, the metadata is
effectively defragmented on the fly.
But, you lose the gains of big consecutive writes for the log area. It
will be really interesting to see how it performs.
> > The ext3 jfs might also need small changes to wok
cleanly with any > > allocate on flush systems (XFS, reiserfs soon).
>
> Aren't there also changes required to the VFS for allocate-on-flush? I
> think this would benefit the performance of all filesystems, but of course
> XFS much more than ext2, because XFS was designed from the start to work
> with this.
>
As far as I know, our current code does not require VFS changes. I
suspect proper integration into the page/buffer cache would make it faster
and more memory efficient though...
> > 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...
>
> It is my understanding also that XFS and ext3 JFS are basically working in
> the same way. The real question would be if the XFS developers want to
> re-work their code to use ext3 JFS and/or if JFS is sufficiently abstract
> to be a plug-in replacement for the XFS journalling code. If it isn't a
> proper superset of what XFS does, it would be an indication that JFS needs
> a bit of rework. AFAIK, the only real feature that JFS doesn't yet implement
> is allowing journalling of multiple filesystems to the same journal, although
> I know this is on Stephen's TODO list.
XFS also allows a dedicated log device, not sure if ext3 does that yet or
not.
-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:22 EST