Re: Description of the Journaling topology

I'm not sure I follow. The journaling will eventually be used as part
of the cache coherency mechanism but that isn't how it is being used
initially. The shortest description of what our journaling will do
is simply that it will record every filesystem operation performed to
a decriptor which might just happen to be a socket. If the network
link between the originating machine and the target machine is fast
enough, the journal we represent a near real-time copy of the originating
machine's filesystem.

Filesystems do not have to be aware of this aspect of the journaling
mechanism. e.g. for UFS one would still (at least for now) fsck
normally after a crash, but one would also be able to rerun portions of
the journal to recover any data buffered but not written to the filesystem
at the time of the crash (if the journal's connection to the target
machine was fast enough to get the data to the target box before the
machine crashed).

That's only true if the journal is written to persistent storage on the
receiving end. How will you guarantee that the journal will be in synch
with the actual file system--will operations slow down until the journal
can be sent/acknowledged or will you allow large windows of buffered
data to accumulate before the receiving end acknowledges them (in which
case the journal won't be very useful for crash recovery or coherency)?