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