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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
