> 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! Best, Tao _______________________________________________ Lustre-discuss mailing list [email protected] http://lists.lustre.org/mailman/listinfo/lustre-discuss
