DragonFly BSD
DragonFly kernel List (threaded) for 2004-12
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Description of the Journaling topology


From: Gary Thorpe <gathorpe79@xxxxxxxxx>
Date: Wed, 29 Dec 2004 23:52:21 -0500

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?




[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]