[Lustre-discuss] question about dcache revalidate

Lai Siyao laisiyao at whamcloud.com
Tue Jan 17 01:43:40 PST 2012

On Tue, Jan 17, 2012 at 5:13 PM, <tao.peng at emc.com> wrote:

> > On Jan 12, 2012, at 3:52 AM, Lai Siyao wrote:
> >
> > > No, to add a dentry to hash client needs holding LOOKUP lock, but
> lustre client unhash (see
> > ll_unhash_aliases()) doesn't really remove dentry from hash, but set
> > the race you mentioned, another process may add the dentry but later the
> lock is canceled soon, so at
> > the time of revalidate, it needs to do a real lookup.
> >
> > In fact there's more to it.
> > Certain operations like open, for example, don't actually get a lock
> from server so if there was no
> > lock to begin with, we add
> > the "known invalid" entry to the hash and immediately mark it as
> invalid, no later lock cancel needed
> > to trigger this.
> >
> > Are you referring to ll_lookup_it_finish() that flag negative dentry
> DCACHE_LUSTRE_INVALID and hash/unhash it immediately if client doesn't have
> UDATE lock? Looks like such dentry is skipped during link path walk as
> ll_dcompare checks DCACHE_LUSTRE_INVALID. Or am I looking at wrong place?
> > Normally lustre client doesn't fetch any child lock for lookup(IT_OPEN),
> but a child dentry will be inserted into hash, however this dentry is
> marked INVALID, and it will be freed after file->release(), that means, no
> other processes will use the dentry (in this case other processes will
> create another dentry for this file and add to hash too). So Oleg means a
> dentry may be inserted into hash without LOOKUP lock, but this dentry won't
> be used by others, so it will not cause the race you mentioned.
> I see. mdc_intent_open_pack() only asks for child OPEN and parent UPDATE
> lock. Thanks very much!

No, generally only nfsd-exported lustre client requests child OPEN lock.

- Lai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-discuss-lustre.org/attachments/20120117/d0a8a549/attachment.htm>

More information about the lustre-discuss mailing list