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

List:       ocfs2-devel
Subject:    Re: [Ocfs2-devel] What's the need of OCFS2_INODE_MAYBE_ORPHANED?
From:       Goldwyn Rodrigues <rgoldwyn () suse ! de>
Date:       2014-01-15 15:35:36
Message-ID: 52D6AAC8.90107 () suse ! de
[Download RAW message or body]

On 01/13/2014 09:42 AM, Joel Becker wrote:
> On Thu, Jan 09, 2014 at 11:27:15AM -0600, Goldwyn Rodrigues wrote:
>>>> Yes, I did not consider that.
>>>> How about using open locks ro_holders count to identify this? That may
>>>> just work. Thanks!
>>> One problem I see in using open lock for this is it could be late.
>>> Consider the scenario where node A removes the dentry and then the node
>>> crashes before trying the try_open_lock. Node B does the file close
>>> later but it doesn't know that the file was unlinked and doesn't do the
>>> clean up.
>>>
>>> To me it appears OCFS2_INODE_MAYBE_ORPHANED is necessary. Any delay it
>>> is causing must be addressed differently.
>>
>> No, I don't mean to remove the OCFS2_INODE_MAYBE_ORPHANED flag, but set
>> it conditionally in ocfs2_dentry_convert_worker() based on the value of
>> the open locks held.
>
> I'm confused by what you are attempting here.  We hold the dentry lock
> until the final dpu() (see the comment in fs/ocfs2/dcache.c).  We should
> never have ro_holders==0 unless we're flushing the entry from the
> dcache.  Do you mean something else?
>

No, I meant exactly that and I thought wrong. However, the patch 
reversals pointed out by Srini have helped.

Thanks for the inputs,

-- 
Goldwyn

_______________________________________________
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel
[prev in list] [next in list] [prev in thread] [next in thread]