From: Sunil Mushran <sunil.mushran@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [PATCH 0/3] ocfs2: fix slow deleting
Date: Tue, 05 Jul 2011 23:17:39 -0700 [thread overview]
Message-ID: <4E13FE03.5060005@oracle.com> (raw)
In-Reply-To: <201107060529.p665TY59014082@acsmt356.oracle.com>
On 07/05/2011 09:38 PM, Wengang Wang wrote:
> There is a use case that the app deletes huge number(XX kilo) of files in every
> 5 minutes. The deletions of some specific files are extreamly slow(costing
> xx~xxx seconds). That is unacceptable.
>
> Reading out the dir entries and the relavent inodes cost time. And we are doing
> that with i_mutex held, it causes unlink path waiting on the mutex for long time.
>
> fix:
> We drops and retake the mutex in the duration giving change to unlink to go on.
> Also, for live nodes, one node only scan and recover this slot where the node
> resides(helps performance). And always do it at each scan time. For those dead
> (not mounted), we do it when we "should". And for dead slots, no dropping-retaking
> mutex is needed.
Yes, this is a good issue to tackle. I will read the patch in greater detail
later. But offhand, I have two comments.
1. "should" is not descriptive. I am assuming you mean do it only during
actual recovery. If so, that would be incorrect. Say node 0 unlinks a file
that was being used by node 1. Node 0 dies. Recovery will notice that
that inode is active and not delete it. If node 1 dies, or is unable to
delete
the file for any other reason, then our only hope is orphan scan.
2. All nodes have to scan all slots. Even live slots. I remember we did for
a reason. And that reason should be in the comment in the patch written
by Srini.
next prev parent reply other threads:[~2011-07-06 6:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-06 4:38 [Ocfs2-devel] [PATCH 0/3] ocfs2: fix slow deleting Wengang Wang
2011-07-06 6:17 ` Sunil Mushran [this message]
2011-07-06 6:41 ` Wengang Wang
2011-07-06 6:48 ` Wengang Wang
2011-07-07 6:19 ` Srinivas Eeda
2011-07-07 20:02 ` Sunil Mushran
2011-07-07 20:26 ` Sunil Mushran
2011-07-08 7:02 ` Srinivas Eeda
2011-07-08 16:18 ` Sunil Mushran
2011-07-28 10:14 ` Joel Becker
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=4E13FE03.5060005@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.