On Tue, Jan 17, 2012 at 5:13 PM, <[email protected]> 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 > 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? > > > 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. Bye, - Lai
_______________________________________________ Lustre-discuss mailing list [email protected] http://lists.lustre.org/mailman/listinfo/lustre-discuss
