Re: Description of the Journaling topology
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?
討論串 (同標題文章)
完整討論串 (本文為第 31 之 42 篇)：