Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754285AbZIVQkU (ORCPT ); Tue, 22 Sep 2009 12:40:20 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751480AbZIVQkT (ORCPT ); Tue, 22 Sep 2009 12:40:19 -0400 Received: from serv2.oss.ntt.co.jp ([222.151.198.100]:58129 "EHLO serv2.oss.ntt.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751281AbZIVQkS (ORCPT ); Tue, 22 Sep 2009 12:40:18 -0400 Message-ID: <4AB8FE25.90806@oss.ntt.co.jp> Date: Wed, 23 Sep 2009 01:41:09 +0900 From: Fernando Luis Vazquez Cao User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Al Viro CC: Christoph Hellwig , t-sato@yk.jp.nec.com, m-hamaguchi@ys.jp.nec.com, Andrew Morton , Linux Kernel Mailing List , Eric Sandeen Subject: Re: [PATCH 3/4] Do not allow umounting of frozen filesystems References: <4A94C151.8020900@oss.ntt.co.jp> <20090826173839.GA20175@lst.de> <4A965BD1.205@oss.ntt.co.jp> <4A9692CF.80508@oss.ntt.co.jp> <20090922110737.GL5858@ZenIV.linux.org.uk> In-Reply-To: <20090922110737.GL5858@ZenIV.linux.org.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1949 Lines: 54 Al Viro さんは書きました: > On Thu, Aug 27, 2009 at 11:06:07PM +0900, Fernando Luis V?zquez Cao wrote: > >> Instead of making umount users wait until the filesystem is >> unfreezed return EBUSY, which is very convenient in HA >> configurations. >> >> This could have been implemented at a lower level but it would >> require considerable plumbing in functions such as release_mounts >> which do not return errors. >> > > >> + if (sb->s_bdev != NULL) { >> + mutex_lock(&sb->s_bdev->bd_fsfreeze_mutex); >> + if (sb->s_frozen != SB_UNFROZEN) { >> + mutex_unlock(&sb->s_bdev->bd_fsfreeze_mutex); >> + return -EBUSY; >> + } >> + } >> > > NAK. First of all, it _partially_ breaks umount -l for no good reason. > If the first fs on the mountpoint is frozen, we fail; if it's deeper > we succeed just fine (and delay actual fs shutdown until the thaw). > > As far as I can see, the real problem is that fsthaw ioctl has braindead > API; it takes some opened file on fs in question. Why not do a bdev > ioctl instead? Then we could let umount go ahead just fine, leaving > fs frozen (and not shut down until it thaws). And whoever does thaw > (via bdev ioctl) will automatically trigger the actual fs shutdown. > Just with Christoph's pair of patches... > I basically agree with you. The current API creates a lot of locking issues that could be tackled more cleanly with the bdev ioctls you suggest. > IOW, I'd rather add two new ioctls (check if frozen/thaw), both by > bdev. On top of the first two patches in this set. > I am happy to see you would welcome a check ioctl. If there is consensus on the bdev ioctl approach I could send patches. Thanks, Fernando -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/