From patchwork Wed Aug 17 08:20:22 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tao Ma X-Patchwork-Id: 110296 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 9002EB6F98 for ; Wed, 17 Aug 2011 18:22:01 +1000 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751970Ab1HQIV5 (ORCPT ); Wed, 17 Aug 2011 04:21:57 -0400 Received: from oproxy6-pub.bluehost.com ([67.222.54.6]:36672 "HELO oproxy6-pub.bluehost.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1750853Ab1HQIV4 (ORCPT ); Wed, 17 Aug 2011 04:21:56 -0400 Received: (qmail 23803 invoked by uid 0); 17 Aug 2011 08:21:55 -0000 Received: from unknown (HELO box585.bluehost.com) (66.147.242.185) by cpoproxy3.bluehost.com with SMTP; 17 Aug 2011 08:21:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tao.ma; s=default; h=Message-Id:Date:Subject:Cc:To:From; bh=t39nY1l8WNWL3qBKK7qDl0zO1/KjL2ItNRGq7M/Mq/g=; b=FJFyWkaCioNjTOP7J4Pt8cmZwbFGicq3wgr/PUeKcEOWKh99CWiPd4OyEcW7osjzBuRfPBD0/QkDWlr212xs2aOx8FCgyibxwPD3wb9mt5wpA52reXpUbf/++e6xx0Zs; Received: from [182.92.247.2] (helo=tma-laptop1.taobao.ali.com) by box585.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1QtbNq-0005di-Lb; Wed, 17 Aug 2011 02:21:55 -0600 From: Tao Ma To: linux-ext4@vger.kernel.org Cc: Yu Jian , Andreas Dilger , "Theodore Ts'o" Subject: [PATCH] ext4: Don't set s_buddy_cache->i_ino to EXT4_BAD_INO Date: Wed, 17 Aug 2011 16:20:22 +0800 Message-Id: <1313569222-5079-1-git-send-email-tm@tao.ma> X-Mailer: git-send-email 1.7.4.1 X-Identified-User: {1390:box585.bluehost.com:colyli:tao.ma} {sentby:smtp auth 182.92.247.2 authed with tm@tao.ma} Sender: linux-ext4-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-ext4@vger.kernel.org From: Tao Ma In 85fe4025, Christoph removed get_next_ino() from new_inode() and do s_buddy_cache->i_ino = get_next_ino(); And then 48e6061b gives EXT4_BAD_INO to this inode. But actually s_buddy_cache is used directly and we never get it from an inode number. So it should be safe for us to not set i_ino at all and I guess that is the case Christoph described in his commit log of 85fe4025 "For a few more filesystems we can avoid assigning any inode number given that they aren't user visible". Cc: Yu Jian Cc: Andreas Dilger Cc: "Theodore Ts'o" Signed-off-by: Tao Ma --- fs/ext4/mballoc.c | 5 ----- 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c index 17a5a57..982f783 100644 --- a/fs/ext4/mballoc.c +++ b/fs/ext4/mballoc.c @@ -2342,11 +2342,6 @@ static int ext4_mb_init_backend(struct super_block *sb) ext4_msg(sb, KERN_ERR, "can't get new inode"); goto err_freesgi; } - /* To avoid potentially colliding with an valid on-disk inode number, - * use EXT4_BAD_INO for the buddy cache inode number. This inode is - * not in the inode hash, so it should never be found by iget(), but - * this will avoid confusion if it ever shows up during debugging. */ - sbi->s_buddy_cache->i_ino = EXT4_BAD_INO; EXT4_I(sbi->s_buddy_cache)->i_disksize = 0; for (i = 0; i < ngroups; i++) { desc = ext4_get_group_desc(sb, i, NULL);