Description of the Journaling topology

Gary Thorpe gathorpe79 at yahoo.com
Wed Dec 29 20:52:21 PST 2004


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?






More information about the Kernel mailing list