Re: [RFC 0/9 v3] fsfreeze: miscellaneous fixes and cleanups

[Eric Sandeen <sandeen@redhat.com>]

On 9/13/12 9:20 PM, Fernando Luis Vazquez Cao wrote:
> On 2012/09/14 09:57, Dave Chinner wrote:
>> On Thu, Sep 13, 2012 at 07:57:42PM +0900, Fernando Luis Vázquez Cao wrote:
>>> This patch set is to address long standing issues in the filesytem freeze code
>>> and to fill some functionality gaps in the API. Some minor code rearrangements
>>> are included too.
>>>
>>> The following patches are included:
>>>
>>> ---
>>> [1/9] vfs: add __iterate_supers() helper
>>> [2/9] fsfreeze: add unlocked version of thaw_super
>>>
>>> Preparatory patches to fix s_umount lockup of emergency thaw code.
>>>
>>> [3/9] fsfreeze: Prevent emergency thaw from looping infinitely
>>>
>>> Fix thaw_bdev so that it propagates the error code properly to the caller.
>>> This bug caused emergency thaw to loop infinitely. This is a forward port of
>>> a previous patch by Dave Chinner.
>>>
>>> [4/9] fsfreeze: emergency thaw will deadlock on s_umount
>>>
>>> Avoid emergency thaw deadlock on s_umount by using unlocked version of
>>> thaw_super() and __iterate_supers()i (introduced in patches 2 and 1
>>> respectively).
>> Given the problems with emergency thaw, this interface has never
>> really worked. In the absence of any obvious need for the
>> functionality (i.e. nobody has reported that it is broken since it
>> was introduced), why don't we simply remove it?
>>
>> IIRC, the emergency thaw code was only added to alleviate
>> fear-mongering about systems getting stuck with unfreezable ext4
>> filesystems (after the "freeze w/ timeout" extensions were knocked
>> back), and time has indicated those fears were unfounded.
>>
>> So, rather than trying to fix the emergency thaw mess, I say we
>> nuke it from orbit....
> 
> As I commented to Eric, In virtualization environments it comes in
> handy sometimes. For example, in an emergency case where a guest
> agent dies leaving one or more filesystems frozen emergency thaw
> is useful.

Except it hasn't actually worked for 2 years, so it really probably
hasn't been handy at all, in practice.

> Hopefully my fix is correct and we can keep this feature.

The fix comes at a cost of quite a lot of complexity and rewriting, though.
We can always write more and more complex code, for weird administrative
corner cases, but is it worth it?  I'm not quite convinced yet.

-Eric

> 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