Re: Description of the Journaling topology

[David Cuthbert <dacut@xxxxxxxxx>]

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?