X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,STOX_REPLY_TYPE autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m8BBATnq001438 for ; Thu, 11 Sep 2008 04:10:29 -0700 X-ASG-Debug-ID: 1221131518-31b803d50000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from tyo201.gate.nec.co.jp (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 31CCE42BCF6 for ; Thu, 11 Sep 2008 04:11:58 -0700 (PDT) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by cuda.sgi.com with ESMTP id ADEBpJOTPjAkTy9p for ; Thu, 11 Sep 2008 04:11:58 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.193]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id m8BBB8Cd020993; Thu, 11 Sep 2008 20:11:08 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id m8BBB8e23001; Thu, 11 Sep 2008 20:11:08 +0900 (JST) Received: from matabe.jp.nec.com (matabe.jp.nec.com [10.26.220.20]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id m8BBB8vN007847; Thu, 11 Sep 2008 20:11:08 +0900 (JST) Received: from TNESB07336 ([10.64.168.65] [10.64.168.65]) by mail.jp.nec.com with ESMTP; Thu, 11 Sep 2008 20:11:07 +0900 Message-ID: <059C75EDB49641A49EF986D81EED4200@nsl.ad.nec.co.jp> From: "Takashi Sato" To: "Christoph Hellwig" Cc: "Andrew Morton" , "Christoph Hellwig" , "Oleg Nesterov" , , , , , , , , References: <20080908205245t-sato@mail.jp.nec.com> <20080908171020.GA22521@infradead.org> In-Reply-To: <20080908171020.GA22521@infradead.org> X-ASG-Orig-Subj: Re: [PATCH 1/3] Implement generic freeze feature Subject: Re: [PATCH 1/3] Implement generic freeze feature Date: Thu, 11 Sep 2008 20:11:06 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 X-Barracuda-Connect: TYO201.gate.nec.co.jp[202.32.8.193] X-Barracuda-Start-Time: 1221131519 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MARKETING_SUBJECT, STOX_REPLY_TYPE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.1.5269 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 STOX_REPLY_TYPE STOX_REPLY_TYPE 0.60 MARKETING_SUBJECT Subject contains popular marketing words Hi, Christoph Hellwig wrote: >> --- linux-2.6.27-rc5.org/fs/block_dev.c 2008-08-29 07:52:02.000000000 +0900 >> +++ linux-2.6.27-rc5-freeze/fs/block_dev.c 2008-09-05 20:00:29.000000000 +0900 >> @@ -285,6 +285,8 @@ static void init_once(void *foo) >> INIT_LIST_HEAD(&bdev->bd_holder_list); >> #endif >> inode_init_once(&ei->vfs_inode); >> + /* Initialize mutex for freeze. */ >> + mutex_init(&bdev->bd_fsfreeze_mutex); > > Why not just freeze_mutex? The Linux kernel has already had the name of "freezer" in the part of power-management. So I named the above mutex "fsfreeze" (filesystem freeze) to distinguish it from the existent "freezer". Andrew pointed it out. >> struct super_block *freeze_bdev(struct block_device *bdev) >> { >> struct super_block *sb; >> >> + mutex_lock(&bdev->bd_fsfreeze_mutex); >> + if (bdev->bd_fsfreeze_count > 0) { >> + bdev->bd_fsfreeze_count++; >> + sb = get_super(bdev); >> + mutex_unlock(&bdev->bd_fsfreeze_mutex); >> + return sb; >> + } >> + bdev->bd_fsfreeze_count++; >> + >> down(&bdev->bd_mount_sem); > > Note that we still have duplication with the bd_mount_sem. I think > you should look into getting rid of it and instead do a check of > the freeze_count under proper freeze_mutex protection. In the original implementation, while the filesystem is frozen, subsequent mounts wait for unfreeze with the semaphore (bd_mount_sem). But if we replace the semphore with the check of the freeze_count, subsequent mounts will abort. I think the original behavior shouldn't be changed, so the existing bd_mount_sem is better. >> @@ -244,6 +274,8 @@ void thaw_bdev(struct block_device *bdev >> } >> >> up(&bdev->bd_mount_sem); >> + mutex_unlock(&bdev->bd_fsfreeze_mutex); >> + return 0; > > Why do you add a return value here if we always return 0 anyway? I forgot to remove the unneeded return value in above old patch. But I need to implement a return value in the new patch because thaw_bdev() needs to return an IO error which occurs in unlockfs(). Eric pointed it out. Cheers, Takashi