[Lustre-discuss] question about dcache revalidate

[tao.peng at emc.com]

Oleg hi,

> -----Original Message-----
> From: Oleg Drokin [mailto:green at whamcloud.com]
> Sent: Friday, January 13, 2012 12:04 AM
> To: Lai Siyao
> Cc: Peng, Tao; Lustre-discuss at lists.lustre.org
> Subject: Re: [Lustre-discuss] question about dcache revalidate
> 
> Hello!
> 
> 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 LUSTRE_DCACHE_INVALID flag. So in
> 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?

Thanks,
Tao

> Bye,
>     Oleg
> >
> > On Wed, Jan 11, 2012 at 10:06 PM, <tao.peng at emc.com> wrote:
> > Hi,
> >
> > I was reading dcache.c and following comments in ll_revalidate_it() seem confusing. Does it mean
> llite can hash a positive dentry to dcache without taking inode LOOKUP lock?
> >
> > 589         /*
> > 590          * This part is here to combat evil-evil race in real_lookup on 2.6
> > 591          * kernels.  The race details are: We enter do_lookup() looking for some
> > 592          * name, there is nothing in dcache for this name yet and d_lookup()
> > 593          * returns NULL.  We proceed to real_lookup(), and while we do this,
> > 594          * another process does open on the same file we looking up (most simple
> > 595          * reproducer), open succeeds and the dentry is added. Now back to
> > 596          * us. In real_lookup() we do d_lookup() again and suddenly find the
> > 597          * dentry, so we call d_revalidate on it, but there is no lock, so
> > 598          * without this code we would return 0, but unpatched real_lookup just
> > 599          * returns -ENOENT in such a case instead of retrying the lookup. Once
> > 600          * this is dealt with in real_lookup(), all of this ugly mess can go and
> > 601          * we can just check locks in ->d_revalidate without doing any RPCs
> > 602          * ever.
> > 603          */
> >
> > Best Regards,
> > Tao
> >
> >
> > _______________________________________________
> > Lustre-discuss mailing list
> > Lustre-discuss at lists.lustre.org
> > http://lists.lustre.org/mailman/listinfo/lustre-discuss
> >
> > _______________________________________________
> > Lustre-discuss mailing list
> > Lustre-discuss at lists.lustre.org
> > http://lists.lustre.org/mailman/listinfo/lustre-discuss
> 
> --
> Oleg Drokin
> Senior Software Engineer
> Whamcloud, Inc.
>