[Lustre-devel] Recovering opens by reconstruction

Alex Zhuravlev Alex.Zhuravlev at Sun.COM
Tue Jul 7 02:56:52 PDT 2009

Nicolas Williams wrote:
> Also, as Oleg explained to me, most open state is for files whose opens
> committed long ago, so most open state is recovered before other
> transactions.  Which means we already have a separate open state
> recovery phase -- it just isn't explicit.  So the only thing that
> changes in my proposal is that all committed open state will be
> recovered by anonymous open by FID reconstruction instead of by replay,
> with all other transactions (including as-yet uncommitted opens) will be
> recovered by replay.

I think it'd be slightly easier to introduce two notions of replay:

1) on-disk replay -- we try to recover some on-disk state from client's cache
    regular requests like mkdir, unlink, rename, setattr, etc

2) in-core replay - we try to recover some in-core state from client's cache
    ldlm locks, open files

the thing is that open(2) is quite interesting in this regard because it does
(1) *and* (2). I believe this is why we used (1) for (2).

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.

thanks, Alex

More information about the lustre-devel mailing list