M> I was under the impression that journal.dat is only intended to get a
M> somehow running system. I mean, what you really want is: have the journal
M> on a separate partition with no filesystem at all. Best of all on a
M> seperate disk (controller, maybe). And you might want to have one journal
M> only for all filesystems. So, journal.dat is an intermediate thing,
M> definitely useful for testing and moving filesystems between ext2 and 3
M> but not what the enduser will want to have.
M> So, rather than concentrating on making journal.dat invisible and what,
M> that is, try to mold a pure intermediate debugging thing into concrete,
M> rather than that: Fix any outstanding ext3 bugs (out of interest: do
M> readonly mounts now work?), then add the journal on different partitions
M> and combined journal of several disk features. This is what you want, not
M> a hack around an invisible journal.dat file. (Ok, if the rest works, you
M> may add it somehow for those that really think they need it).
The experience of XFS on IRIX is that unless you put the journal on
a REALLY fast device, like a battery-backed SSD, then the difference
in performance between an internal journal and an external one is
noise, even on very large, active, and performance-critical
filesystems. Ie: writing to the journal is NOT a bottleneck.
This was quite a surprising result... Though it does imply that
XFS/IRIX got the write ordering, batching, etc correct.
I certainly can't speak for the Ext3 implementation, of course.
-- Scott Henry <scotth@sgi.com> / Help! My disclaimer is missing! IRIX MTS, / GIGO *really* means: Garbage in, Gospel Out Silicon Graphics, Inc / http://reality.sgi.com/scotth/- 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/