From: Mark Fasheh <mfasheh@suse.de>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [patch 02/10] ocfs2: free inode when i_count becomes zero
Date: Wed, 13 Aug 2014 11:03:39 -0700 [thread overview]
Message-ID: <20140813180339.GU2203@wotan.suse.de> (raw)
In-Reply-To: <53e290c2.UrOYpRJudvt5Qabp%akpm@linux-foundation.org>
On Wed, Aug 06, 2014 at 01:32:02PM -0700, Andrew Morton wrote:
> From: Xue jiufei <xuejiufei@huawei.com>
> Subject: ocfs2: free inode when i_count becomes zero
>
> Disk inode deletion may be heavily delayed when one node unlink a file
> after the same dentry is freed on another node(say N1) because of memory
> shrink but inode is left in memory. This inode can only be freed while N1
> doing the orphan scan work.
>
> However, N1 may skip orphan scan for several times because other nodes may
> do the work earlier. In our tests, it may take 1 hour on 4 nodes cluster
> and this will cause bad user experience. So we think the inode should be
> freed when i_count becomes zero to avoid such circumstances.
Firstly, thanks for the patch Xue.
I understand your problem and I definitely agree that it hurts the user
experience. If the inode is free to be deleted we shouldn't be taking so
long to get rid of it.
What I'm worried about is that we're always going to tell the kernel to
evict the inode now, which will always cause some sort of cluster locking.
I need to look at this more and think about it a bit. Maybe there's a better
way?
--Mark
--
Mark Fasheh
next prev parent reply other threads:[~2014-08-13 18:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-06 20:32 [Ocfs2-devel] [patch 02/10] ocfs2: free inode when i_count becomes zero akpm at linux-foundation.org
2014-08-13 18:03 ` Mark Fasheh [this message]
2014-08-30 7:03 ` Xue jiufei
2014-12-02 6:50 ` Xue jiufei
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=20140813180339.GU2203@wotan.suse.de \
--to=mfasheh@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox