Description of the Journaling topology

David Cuthbert dacut at kanga.org
Thu Dec 30 22:12:12 PST 2004


Matthew Dillon wrote:
    Even more key is the off-site capability.  If the journal is a TCP
    connection to another machine the buffering delay could be as little
    as a millisecond before the data gets to the target machine, and the
    local disks would not be impacted at all.  The originating machine 
    could immediately crash without really messing anything up, even if
    the data has not yet been committed to hard storage on the target
    machine.
This is potentially dangerous.  In general, I think you want the 
journalling to occur as close to the storage as possible -- i.e., on the 
*target* machine, not the originating machine.

The scenario I'm thinking of -- one not too uncommon when running 
unwieldy makefiles -- is as follows: (A and B are NFS clients, T is the 
NFS server):

A: rmdir() called
A:   rmdir() journalled
A:   rmdir() sent to server
T: directory is removed
A: crashes
B: mkdir() called on same directory
B:   mkdir() journalled
B:   mkdir() sent to server
B:   mkdir() journal marked as complete.
T: directory is created
[a day later...]
A: reboots, starts replaying journal
A:   rmdir() sent to server
A:   rmdir() journal marked as complete.
T: directory is removed
Thus, one rmdir() call ends up being called twice.  Or am I missing 
something?





More information about the Kernel mailing list