From: Goldwyn Rodrigues <rgoldwyn@suse.de>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] What's the need of OCFS2_INODE_MAYBE_ORPHANED?
Date: Wed, 08 Jan 2014 21:12:47 -0600 [thread overview]
Message-ID: <52CE13AF.5080107@suse.de> (raw)
In-Reply-To: <52CDFB7F.5010200@oracle.com>
Hi Srini,
On 01/08/2014 07:29 PM, Srinivas Eeda wrote:
> Hi Goldwyn,
>
> On 01/08/2014 04:12 PM, Goldwyn Rodrigues wrote:
>> Hi,
>>
>> >From the comments in fs/ocfs2/inode.h:90 it seems, this was used in
>> legacy ocfs2 systems when a node received unlink votes. Since unlink
>> votes has been done away with and replaced with open locks, is this
>> flag still required? If yes, why?
> My understanding is that unlink voting protocol was heavy. So the
> following was done to address it.
>
> To do an unlink, dentry has to be removed. In order to do that the node
> has to get EX lock on the dentry which means all other nodes have to
> downconvert. In general EX lock on dentry is acquired only in unlink and
> I assume rename case. So all nodes which down convert the lock mark
> their inode OCFS2_INODE_MAYBE_ORPHANED. The only problem with this is
> that dentry on a node can get purged because of memory pressure which
> marks inode as OCFS2_INODE_MAYBE_ORPHANED even when no unlink was done
> on this inode.
>
I think you are getting confused between dentry_lock (dentry_lockres)
and open lock (ip_open_lockres). AFAICS, dentry locks are used to
control the remote dentries.
>
>> >From my ongoing investigation of unlink() times, it seems this flag is
>> causing the delay with releasing the open locks while downconverting
>> dentry locks. The flag is set _everytime_ a dentry downconvert is
>> performed even if the file is not scheduled to be deleted. If not, we
>> can be smartly evict the inodes which are *not* to be deleted
>> (i_nlink>0) by not offloading to ocfs2_wq. This way open lock will
>> release faster speeding up unlink on the deleting node.
>>
>>
> Are you referring to the delay caused by ocfs2_drop_dentry_lock queueing
> dentry locks to dentry_lock_list ?. If that's the case, have you tried
> removing following patches which introduced that behavior ? I think that
> quota's deadlock bug might have to be addressed differently ?
>
> ea455f8ab68338ba69f5d3362b342c115bea8e13
Yes, that should make some difference. Let me try that. However, I was
suggesting we do not set the OCFS2_INODE_MAYBE_ORPHANED flag in
ocfs2_dentry_convert_worker as well, but I am not sure of the
consequences and that is the reason I asked why it is used.
> eb90e46458b08bc7c1c96420ca0eb4263dc1d6e5
> bb44bf820481e19381ec549118e4ee0b89d56191
I did not find these gits. Which tree are you referring to?
>
> The above patches were leaving orphan files around which was causing a
> big problem to some applications that removes lot of files which inturn
> caused intermittent hangs
>
--
Goldwyn
next prev parent reply other threads:[~2014-01-09 3:12 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-09 0:12 [Ocfs2-devel] What's the need of OCFS2_INODE_MAYBE_ORPHANED? Goldwyn Rodrigues
2014-01-09 1:29 ` Srinivas Eeda
2014-01-09 3:12 ` Goldwyn Rodrigues [this message]
2014-01-09 5:30 ` Srinivas Eeda
2014-01-09 10:23 ` Joel Becker
2014-01-09 13:35 ` Goldwyn Rodrigues
2014-01-13 15:39 ` Joel Becker
2014-01-09 15:44 ` Goldwyn Rodrigues
2014-01-09 16:06 ` Srinivas Eeda
2014-01-09 16:34 ` Goldwyn Rodrigues
2014-01-09 17:04 ` Srinivas Eeda
2014-01-09 17:27 ` Goldwyn Rodrigues
2014-01-13 15:42 ` Joel Becker
2014-01-15 15:35 ` Goldwyn Rodrigues
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52CE13AF.5080107@suse.de \
--to=rgoldwyn@suse.de \
--cc=ocfs2-devel@oss.oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.