From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fernando Luis Vazquez Cao Subject: Re: [PATCH 6/8] fsfreeze: add vfs ioctl to check freeze state Date: Thu, 13 Sep 2012 17:19:21 +0900 Message-ID: <50519709.7070302@lab.ntt.co.jp> References: <1342083464.7033.6.camel@nexus.lab.ntt.co.jp> <1342084214.7033.16.camel@nexus.lab.ntt.co.jp> <20120713135454.GI20361@quack.suse.cz> <20120715224517.GD2920@dastard> <50517AEB.6060604@lab.ntt.co.jp> <20120913071810.GN11511@dastard> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Jan Kara , Al Viro , Dave Chinner , Christoph Hellwig , linux-fsdevel@vger.kernel.org To: Dave Chinner Return-path: Received: from tama50.ecl.ntt.co.jp ([129.60.39.147]:52066 "EHLO tama50.ecl.ntt.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751669Ab2IMITm (ORCPT ); Thu, 13 Sep 2012 04:19:42 -0400 In-Reply-To: <20120913071810.GN11511@dastard> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 2012/09/13 16:18, Dave Chinner wrote: > On Thu, Sep 13, 2012 at 03:19:23PM +0900, Fernando Luis Vazquez Cao w= rote: >> On 2012/07/16 07:45, Dave Chinner wrote: >>> On Fri, Jul 13, 2012 at 03:54:54PM +0200, Jan Kara wrote: >>>> On Thu 12-07-12 18:10:14, Fernando Luis V=E1zquez Cao wrote: >>>>> The FIISFROZEN ioctl can be use by HA and monitoring software to = check >>>>> the freeze state of a mounted filesystem. >>> Can you explain in more detail why the HA system needs to check thi= s? >>> And, for that matter, what it does with that information? >> What our HA guys told me is that certain fencing scripts >> try to umount filesystems that can be in frozen state. The >> problem is that when we umount a frozen filesystem the >> superblock still stays around which can lead to a split-brain >> scenario. > Then the bug is that unmounting a frozen filesystem is not > working correctly. Fix the problem, don't add new APIs to try to > detect a state where the bug might get tripped over and avoid it. The problem is that we allow users to umount a frozen filesystem but we have neither a bdev level fsfreeze API to thaw it after that nor check ioctls. I proposed returning EBUSY when userspace tries to umount a frozen filesystem, but this would break lazy umount, which I was told by Al Viro and Josef Bacik is a no go, so I discarded this approach. I will follow Al's advice a few years ago and do the following: 1- Let userspace umount frozen filesystems. 2- Provide a bdev level ioctl to unfreeze a umounted filesystem. I will also: 3- add the check ioctls so that users can check whether a filesystem is frozen or not and avoid surprises. The patch set I will be sending later today takes care of 1 and 3 (among other things) and a follow-up patch set will address 2 (need to make some changes to btrfs and get_active_super before it is ready). That said, even if the problem above did not exist it still would be nice to have check ioctls from an API point of view. Thanks, =46ernando -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html