All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sunil Mushran <sunil.mushran@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [PATCH] ocfs2: unlock open_lock immediately
Date: Wed, 31 Aug 2011 10:36:46 -0700	[thread overview]
Message-ID: <4E5E712E.1000600@oracle.com> (raw)
In-Reply-To: <20110831025154.GA5342@laptop.jp.oracle.com>

On 08/30/2011 07:51 PM, Wengang Wang wrote:
> The test case is simple:
> in a three-node cluster,
> 1) node A copies kernel tree to ocfs2 volume
> 2) node B and C keeps "ls -R" the tree which is under copying
> 3) after the copy finished, remove the whole tree by "rm -rf xxx" while
>     Node B and C are still "ls -R"ing.
> 4) stop the "ls -R" on node B/C when "rm" on node A is finished.
> 5) umount all three nodes.
> There are entries left in orphandirs(could for all slots).
> Actually copying whole is time consuming, I can hit the problem when copied part
> of the kernel tree.
>
> I confirmed that the cause is "remotely opened" by printing logs.
> log showed that all the three nodes think "there is other node(s) still opening the inode",
> so they don't do dinode deletion.


Fair enough.

What needs investigating is whether this approach will work in 1.4/1.6
too. evict_inode() was added later.


> Yes, I have also checked into the two functions.
> I found there is no bad effect to call ocfs2_open_unlock() and
> ocfs2_simple_drop_lockres() on openlock twice.
>
> when ocfs2_inode_unlock() is called in ocfs2_clear_inode again, the holders
> should be zero already(in the first call), so no confusing to dlm unlock.
> when ocfs2_mark_lockres_freeing() is called for the second time, the openlock
> should be with OCFS2_LOCK_FREEING flag already, I don't see problem here.
> when ocfs2_drop_lock() is called for the second time, flag OCFS2_LOCK_ATTACHED
> should be cleared already(in first call), so no problem either.
> Maybe I missed something?
>
> Simply removing ocfs2_open_unlock/ocfs2_mark_lockres_freeing from
> ocfs2_clear_inode() and ocfs2_drop_lock from ocfs2_drop_inode_locks()
> respectively can introduce problem:
>
> For ((inode->i_nlink&&
>       !(OCFS2_I(inode)->ip_flags&OCFS2_INODE_MAYBE_ORPHANED))
> case, we still need to call ocfs2_open_unlock() and
> ocfs2_mark_lockres_freeing() against openlock in ocfs2_clear_inode()
> and call ocfs2_drop_lock() in ocfs2_drop_inode_locks().

Good point. No need to add another flag. We may need to add
some comments to explain this.

  reply	other threads:[~2011-08-31 17:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-26  2:50 [Ocfs2-devel] [PATCH] ocfs2: unlock open_lock immediately Wengang Wang
2011-08-31  1:55 ` Sunil Mushran
2011-08-31  2:51   ` Wengang Wang
2011-08-31 17:36     ` Sunil Mushran [this message]
2011-09-01  1:00       ` Wengang Wang
2011-09-07 18:04 ` Joel Becker
2011-09-08  2:14   ` Wengang Wang

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=4E5E712E.1000600@oracle.com \
    --to=sunil.mushran@oracle.com \
    --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.