[Lustre-devel] Recovering opens by reconstruction

Alex Zhuravlev Alex.Zhuravlev at Sun.COM
Tue Jul 7 23:46:54 PDT 2009


Andreas Dilger wrote:
>> my old thougth was that instead of introducing special new open-by-fid RPC
>> we should try to implement open in terms of LDLM locks because it's in-core
>> state (though with specific tracking of unlinked files). given this we'd
>> automatically get single mechanism for all in-core states and we'd get rid
>> of special paths for open replays.
> 
> One problem with this is that the ordering needs to be preserved.  Opens
> that have committed need to be replayed before any other replay operations,
> because those replayed operations may depend on the file being open.
> However, "normal" lock replay should happen after (or conceivably during)
> operation replay so that the objects being locked actually exist and the
> server can (hopefully soon) verify the lock version number during recovery.

well, that ordering is already "dead" due to VBR?

I think semantics of unlink is just to unlink name, everything else is up to
MDS (when to destroy inode and objects). also notice inode destroy is a different
transaction in general (due to possible multi-transaction truncate).

if we decouple unlink and object destroy, then the following sequence should work:
1) replay on-disk states
    (unlink just put inode onto orphan list)
2) replay in-core states
    (including open locks)
... at some point
3) MDS goes over orphan list and destroys selected objects
    (depending on VRB policy, etc)

thanks, Alex




More information about the lustre-devel mailing list