Re: Description of the Journaling topology

[Gary Thorpe <gathorpe79@xxxxxxxxx>]

Matthew Dillon wrote:

>     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)?

Isn't what you want a distributed file system? If not, why not?