From: Fernando Luis Vazquez Cao <fernando_b1@lab.ntt.co.jp>
To: Dave Chinner <david@fromorbit.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
Josef Bacik <jbacik@fusionio.com>,
Eric Sandeen <sandeen@redhat.com>,
Dave Chinner <dchinner@redhat.com>,
Christoph Hellwig <hch@infradead.org>, Jan Kara <jack@suse.cz>,
linux-fsdevel@vger.kernel.org
Subject: Re: [RFC 0/9 v3] fsfreeze: miscellaneous fixes and cleanups
Date: Fri, 14 Sep 2012 11:20:41 +0900 [thread overview]
Message-ID: <50529479.1040503@lab.ntt.co.jp> (raw)
In-Reply-To: <20120914005700.GP11511@dastard>
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.
Hopefully my fix is correct and we can keep this feature.
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-14 2:20 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-13 10:57 [RFC 0/9 v3] fsfreeze: miscellaneous fixes and cleanups Fernando Luis Vázquez Cao
2012-09-13 11:00 ` [PATCH 1/9] vfs: add __iterate_supers() helper Fernando Luis Vázquez Cao
2012-09-14 2:36 ` Eric Sandeen
2012-09-14 2:40 ` Fernando Luis Vazquez Cao
2012-09-13 11:01 ` [RFC 2/9] fsfreeze: add unlocked version of thaw_super Fernando Luis Vázquez Cao
2012-09-13 18:13 ` Eric Sandeen
2012-09-13 11:03 ` [RFC 3/9] fsfreeze: Prevent emergency thaw from looping infinitely Fernando Luis Vázquez Cao
2012-09-13 16:40 ` Eric Sandeen
2012-09-13 11:04 ` [RFC 4/9] fsfreeze: emergency thaw will deadlock on s_umount Fernando Luis Vázquez Cao
2012-09-13 11:07 ` [RFC 5/9] xfs: switch to using super methods for fsfreeze Fernando Luis Vázquez Cao
2012-09-13 11:08 ` [RFC 6/9] fsfreeze: move emergency thaw code to fs/super.c Fernando Luis Vázquez Cao
2012-09-13 19:00 ` Josef Bacik
2012-09-13 21:10 ` Eric Sandeen
2012-09-14 2:11 ` Fernando Luis Vazquez Cao
2012-09-14 1:59 ` Fernando Luis Vazquez Cao
2012-09-13 11:10 ` [PATCH 7/9] fsfreeze: freeze_super and thaw_bdev don't play well together Fernando Luis Vázquez Cao
2012-09-13 11:11 ` [PATCH 8/9] fsfreeze: add vfs ioctl to check freeze state Fernando Luis Vázquez Cao
2012-09-13 11:13 ` [PATCH 9/9] fsfreeze: add block device " Fernando Luis Vázquez Cao
2012-09-14 0:57 ` [RFC 0/9 v3] fsfreeze: miscellaneous fixes and cleanups Dave Chinner
2012-09-14 2:20 ` Fernando Luis Vazquez Cao [this message]
2012-09-14 2:33 ` Eric Sandeen
2012-09-14 2:48 ` Fernando Luis Vazquez Cao
2012-09-14 6:22 ` 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=50529479.1040503@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=jbacik@fusionio.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=sandeen@redhat.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.