From: Fernando Luis Vazquez Cao <fernando_b1@lab.ntt.co.jp>
To: Dave Chinner <david@fromorbit.com>
Cc: Jan Kara <jack@suse.cz>, Al Viro <viro@zeniv.linux.org.uk>,
Dave Chinner <dchinner@redhat.com>,
Christoph Hellwig <hch@infradead.org>,
linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 6/8] fsfreeze: add vfs ioctl to check freeze state
Date: Thu, 13 Sep 2012 17:19:21 +0900 [thread overview]
Message-ID: <50519709.7070302@lab.ntt.co.jp> (raw)
In-Reply-To: <20120913071810.GN11511@dastard>
On 2012/09/13 16:18, Dave Chinner wrote:
> On Thu, Sep 13, 2012 at 03:19:23PM +0900, Fernando Luis Vazquez Cao wrote:
>> 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ázquez 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 this?
>>> 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,
Fernando
--
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
next prev parent reply other threads:[~2012-09-13 8:19 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-12 8:57 [PATCH 0/8 v2] fsfreeze: miscellaneous fixes and cleanups Fernando Luis Vázquez Cao
2012-07-12 9:02 ` [PATCH 1/8] fsfreeze: Prevent emergency thaw from looping infinitely Fernando Luis Vázquez Cao
2012-07-13 12:59 ` Jan Kara
2012-07-17 5:13 ` Fernando Luis Vazquez Cao
2012-07-12 9:04 ` [PATCH 2/8] fsfreeze: emergency thaw will deadlock on s_umount Fernando Luis Vázquez Cao
2012-07-13 13:17 ` Jan Kara
2012-08-09 6:00 ` Fernando Luis Vazquez Cao
2012-09-13 6:23 ` Fernando Luis Vazquez Cao
2012-07-12 9:05 ` [PATCH 3/8] fsfreeze: freeze_super and thaw_bdev don't play well together Fernando Luis Vázquez Cao
2012-07-13 13:45 ` Jan Kara
2012-08-09 9:00 ` Fernando Luis Vazquez Cao
2012-07-12 9:07 ` [PATCH 4/8] fsfreeze: switch to using super methods where possible Fernando Luis Vázquez Cao
2012-07-13 13:50 ` Jan Kara
2012-07-12 9:09 ` [PATCH 5/8] fsfreeze: move emergency thaw code to fs/super.c Fernando Luis Vázquez Cao
2012-07-13 13:53 ` Jan Kara
2012-07-12 9:10 ` [PATCH 6/8] fsfreeze: add vfs ioctl to check freeze state Fernando Luis Vázquez Cao
2012-07-13 13:54 ` Jan Kara
2012-07-15 22:45 ` Dave Chinner
2012-09-13 6:19 ` Fernando Luis Vazquez Cao
2012-09-13 7:18 ` Dave Chinner
2012-09-13 8:19 ` Fernando Luis Vazquez Cao [this message]
2012-09-14 0:15 ` Dave Chinner
2012-09-14 1:46 ` Fernando Luis Vazquez Cao
2012-09-14 6:28 ` Dave Chinner
2012-09-14 8:18 ` Fernando Luis Vazquez Cao
2012-09-13 6:11 ` Fernando Luis Vazquez Cao
2012-07-12 9:11 ` [PATCH 7/8] fsfreeze: add block device " Fernando Luis Vázquez Cao
2012-07-12 9:12 ` [PATCH 8/8] fsfreeze: update Documentation/filesystems/Locking Fernando Luis Vázquez Cao
2012-07-13 14:11 ` Jan Kara
2012-07-17 1:42 ` Fernando Luis Vazquez Cao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50519709.7070302@lab.ntt.co.jp \
--to=fernando_b1@lab.ntt.co.jp \
--cc=david@fromorbit.com \
--cc=dchinner@redhat.com \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).