> When reading the GlusterFS replication description - it seemed like they > discussed what happens if a node goes down *during* the unlink(), but they > didn't specifically cover what happens if the node is down before and after > the unlink(), but then brought back up some time later. One interpretation > suggested to me that the journal would not hang around, and the file would > be treated as gone from all "up" nodes, and then when the later node is > brought back up, the file shows up as existing on only one node, and the > self-heal would kick in and replicate the file as if it still exists. I > didn't find the time to test this exact scenario yet, though... >From a top level - if the unlink() system call has returned success back to the app, then your file is assured to be deleted no matter at what stage any server went down. If a server is already down even before of the unlink() call was initiated by the app, then the file is deleted when the server comes back up. If a server is brough down in the middle of an unlink transaction, no matter at what stage of the transaction (out of the 5 stages - lock, journal, act, unjournal, unlock) then the file is assured to get deleted (if it the server went down before the 'act's tage) when the server comes back - provided the transaction has proceeded to completion on atleast one server. Avati
