From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Sandeen Subject: Re: [RFC 0/9 v3] fsfreeze: miscellaneous fixes and cleanups Date: Thu, 13 Sep 2012 21:33:33 -0500 Message-ID: <5052977D.7000305@redhat.com> References: <1347533862.5646.2.camel@nexus.lab.ntt.co.jp> <20120914005700.GP11511@dastard> <50529479.1040503@lab.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Dave Chinner , Al Viro , Josef Bacik , Dave Chinner , Christoph Hellwig , Jan Kara , linux-fsdevel@vger.kernel.org To: Fernando Luis Vazquez Cao Return-path: Received: from mx1.redhat.com ([209.132.183.28]:60916 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754623Ab2INCdo (ORCPT ); Thu, 13 Sep 2012 22:33:44 -0400 In-Reply-To: <50529479.1040503@lab.ntt.co.jp> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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=E1zquez Ca= o 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 rea= rrangements >>> 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 forwar= d 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.... >=20 > 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, tho= ugh. We can always write more and more complex code, for weird administrativ= e 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