Message ID | 53980026.8050508@huawei.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show
Return-Path: <ocfs2-devel-bounces@oss.oracle.com> X-Original-To: patchwork-ocfs2-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 0C7E2BEEAA for <patchwork-ocfs2-devel@patchwork.kernel.org>; Wed, 11 Jun 2014 07:15:18 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 363D42022A for <patchwork-ocfs2-devel@patchwork.kernel.org>; Wed, 11 Jun 2014 07:15:17 +0000 (UTC) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BCCE5201C0 for <patchwork-ocfs2-devel@patchwork.kernel.org>; Wed, 11 Jun 2014 07:15:15 +0000 (UTC) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5B7ERLH025953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Jun 2014 07:14:28 GMT Received: from oss.oracle.com (oss-external.oracle.com [137.254.96.51]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5B7EM9n029071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2014 07:14:22 GMT Received: from localhost ([127.0.0.1] helo=oss.oracle.com) by oss.oracle.com with esmtp (Exim 4.63) (envelope-from <ocfs2-devel-bounces@oss.oracle.com>) id 1Wucgj-00018F-6a; Wed, 11 Jun 2014 00:11:13 -0700 Received: from ucsinet22.oracle.com ([156.151.31.94]) by oss.oracle.com with esmtp (Exim 4.63) (envelope-from <xuejiufei@huawei.com>) id 1WucgR-00017r-7I for ocfs2-devel@oss.oracle.com; Wed, 11 Jun 2014 00:10:55 -0700 Received: from userp1020.oracle.com (userp1020.oracle.com [156.151.31.79]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s5B7AsH6012959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <ocfs2-devel@oss.oracle.com>; Wed, 11 Jun 2014 07:10:54 GMT Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by userp1020.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5B7Ak0k007833 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=FAIL) for <ocfs2-devel@oss.oracle.com>; Wed, 11 Jun 2014 07:10:49 GMT Received: from 172.24.2.119 (EHLO szxeml212-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWR55346; Wed, 11 Jun 2014 15:10:24 +0800 (CST) Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 11 Jun 2014 15:09:27 +0800 Received: from [127.0.0.1] (10.177.22.96) by szxeml415-hub.china.huawei.com (10.82.67.154) with Microsoft SMTP Server id 14.3.158.1; Wed, 11 Jun 2014 15:09:28 +0800 Message-ID: <53980026.8050508@huawei.com> Date: Wed, 11 Jun 2014 15:07:18 +0800 From: Xue jiufei <xuejiufei@huawei.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Andrew Morton <akpm@linux-foundation.org>, Mark Fasheh <mfasheh@suse.com> X-Originating-IP: [10.177.22.96] X-CFilter-Loop: Reflected X-Flow-Control-Info: class=Pass-to-MM reputation=ipRisk-All ip=119.145.14.64 ct-class=T1 ct-vol1=0 ct-vol2=6 ct-vol3=5 ct-risk=10 ct-spam1=0 ct-spam2=0 ct-bulk=91 rcpts=1 size=1251 X-Sendmail-CM-Score: 0.00% X-Sendmail-CM-Analysis: v=2.1 cv=MqdrtQqe c=1 sm=1 tr=0 a=6YMIiCGU//PUEf62qScyBg==:117 a=6YMIiCGU//PUEf62qScyBg==:17 a=vhjsbW97bagA:10 a=eMpGtoyIjXcA:10 a=O9dq5j03pVQA:10 a=-6GgXGw8a1AA:10 a=0icaLGduHPcA:10 a=8nJEP1OIZ-IA:10 a=i0EeH86SAAAA:8 a=2o_UiRrbhhHYyDG31 ecA:9 a=wPNLvfGTeEIA:10 a=hPjdaMEvmhQA:10 X-Sendmail-CT-RefID: str=0001.0A090207.539800FA.0147:SCFSTAT1612107, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-Sendmail-CT-Classification: not spam Cc: ocfs2-devel@oss.oracle.com Subject: [Ocfs2-devel] [PATCH] ocfs2: free inode when i_count becomes zero X-BeenThere: ocfs2-devel@oss.oracle.com X-Mailman-Version: 2.1.9 Precedence: list Reply-To: xuejiufei@huawei.com List-Id: <ocfs2-devel.oss.oracle.com> List-Unsubscribe: <https://oss.oracle.com/mailman/listinfo/ocfs2-devel>, <mailto:ocfs2-devel-request@oss.oracle.com?subject=unsubscribe> List-Archive: <http://oss.oracle.com/pipermail/ocfs2-devel> List-Post: <mailto:ocfs2-devel@oss.oracle.com> List-Help: <mailto:ocfs2-devel-request@oss.oracle.com?subject=help> List-Subscribe: <https://oss.oracle.com/mailman/listinfo/ocfs2-devel>, <mailto:ocfs2-devel-request@oss.oracle.com?subject=subscribe> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ocfs2-devel-bounces@oss.oracle.com Errors-To: ocfs2-devel-bounces@oss.oracle.com X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP |
diff --git a/fs/ocfs2/inode.c b/fs/ocfs2/inode.c index 437de7f..a490bc5 100644 --- a/fs/ocfs2/inode.c +++ b/fs/ocfs2/inode.c @@ -1192,17 +1192,9 @@ void ocfs2_evict_inode(struct inode *inode) int ocfs2_drop_inode(struct inode *inode) { struct ocfs2_inode_info *oi = OCFS2_I(inode); - int res; - trace_ocfs2_drop_inode((unsigned long long)oi->ip_blkno, inode->i_nlink, oi->ip_flags); - - if (oi->ip_flags & OCFS2_INODE_MAYBE_ORPHANED) - res = 1; - else - res = generic_drop_inode(inode); - - return res; + return 1; } /*
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 inode should be freed when i_count becomes zero to avoid such circumstances. Signed-off-by: joyce.xue <xuejiufei@huawei.com> --- fs/ocfs2/inode.c | 10 +--------- 1 file changed, 1 insertion(+), 9 deletions(-)