[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lustre-discuss
Subject:    [Lustre-discuss] renamed directory retains a dentry under its old name?
From:       sdm900 () gmail ! com (Stuart Midgley)
Date:       2009-11-22 9:35:47
Message-ID: 67991D15-C8E0-48F4-8B93-562854BDB922 () gmail ! com
[Download RAW message or body]

Lustre serves us very very well.  As Phil points out, these sort of bugs are not show \
stoppers for us, we report them to improve the code.

We have 30oss's and ~300TB of storage under it.


-- 
Dr Stuart Midgley
sdm900 at gmail.com



On 22/11/2009, at 17:24 , Phil Schwan wrote:

> Hello, my good man!
> 
> 2009/11/20 Oleg Drokin <Oleg.Drokin at sun.com>
> 
> Yes, I think this does match bug 2969 behavior.
> We add entry to dcache without lock (not visible in the trace you provided). Then \
> we do rename, then we do some sort of stat on a renamed entry and reobtain the \
> lock. Then we do stat on old name, and since lock is on inode - we find the newly \
> reinstantiated lock and declare old dentry as valid.
> 
> Hmm.  My first instinct was that there shouldn't be dentries without locks, but \
> it's been sufficiently long that I can't remember all the details of the dentry \
> life cycle.  What you wrote certainly sounds like a plausible explanation. 
> I wonder if my patch for 20323 would have helped this case
> (or have just always returning the lock), though on the other hand this
> is inode from mkdir and so might have never go through open path.
> Bug 16417 is what landed into 1.8.2 and is a complete rework of
> dcache caching logic for dentries and has a better chance of fixing this,
> I would say.
> If not, it would be great if the lock will start earlier in time, definitely
> before rename happens.
> 
> I hope this problem did not ruin your day in the end.
> 
> No, no, it's fairly minor for us.  I just wanted to report it in case we were the \
> first to experience it.  We will probably upgrade at some point, but we had a \
> less-than-perfect experience with an upgrade this year, so I imagine Stu will wait \
> until it's really necessary. 
> Thanks for looking into it.  From skimming 16417, I agree that it stands a good \
> chance of fixing it, or at least permutes the system sufficiently that it'd be \
> worth trying to reproduce it again after an upgrade. 
> And we do miss you. Does your coming with such a question means you are on your way \
> back to us? ;) 
> You all seem to be doing just fine without me. :)  We certainly make intense use of \
> Lustre in our unending quest to find dinosaur blood, and it serves us very well. 
> Cheers,
> 
> -p
> _______________________________________________
> Lustre-discuss mailing list
> Lustre-discuss at lists.lustre.org
> http://lists.lustre.org/mailman/listinfo/lustre-discuss


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic