From: Eric Sandeen <sandeen@redhat.com>
To: Jan Kara <jack@suse.cz>
Cc: Eric Sandeen <sandeen@sandeen.net>,
Kamal Mostafa <kamal@canonical.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Matthew Wilcox <matthew@wil.cx>,
Randy Dunlap <rdunlap@xenotime.net>, Theodore Tso <tytso@mit.edu>,
linux-doc@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Surbhi Palande <csurbhi@gmail.com>,
Valerie Aurora <val@vaaconsulting.com>,
Christopher Chaltain <christopher.chaltain@canonical.com>,
"Peter M. Petrakis" <peter.petrakis@canonical.com>,
Mikulas Patocka <mpatocka@redhat.com>,
Surbhi Palande <surbhi.palande@canonical.com>
Subject: Re: [PATCH v2 1/7] Adding support to freeze and unfreeze a journal
Date: Tue, 10 Jan 2012 21:08:27 -0600 [thread overview]
Message-ID: <4F0CFD2B.7010404@redhat.com> (raw)
In-Reply-To: <20120110213104.GI4516@quack.suse.cz>
On 1/10/12 3:31 PM, Jan Kara wrote:
> On Tue 10-01-12 14:20:23, Eric Sandeen wrote:
<snip>
>> Hrm let me think through this a little more; we actually do:
>>
>> t16) ext4_journal_start()
>> t17) ext4_journal_start_sb()
>> t18) handle = ext4_journal_current_handle();
>> t19) if (!handle) vfs_check_frozen()
>> t20) ... jbd2_journal_start()
> Ah, right. I forgot.
>
>> So actually we *do* block new handles, but let *existing* ones
>> continue (see commits 6b0310fbf087ad6e9e3b8392adca97cd77184084
>> and be4f27d324e8ddd57cc0d4d604fe85ee0425cba9)
>>
>> So your assertion that a new handle is started is incorrect
>> in general, isn't it? So then does the fix seem necessary?
>> Or, at least, in the fashion below - maybe we need to just make
>> sure all started handles complete before the unlock_updates?
>> Or am I missing something...?
> Well, the problem with running operations and freezing is more
> fundamental I believe. See my email
> http://marc.info/?l=linux-fsdevel&m=132585911925796&w=2
>
> So I believe we'll need some better exclusion mechanism already in VFS.
>
> Honza
>
Yep, saw it, just wasn't sure if this patchset was still under active consideration.
Thanks,
-Eric
next prev parent reply other threads:[~2012-01-11 3:09 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-08 18:04 [PATCH v2 0/7] fix s_umount thaw/write and journal deadlock Kamal Mostafa
2011-12-08 18:04 ` [PATCH v2 1/7] Adding support to freeze and unfreeze a journal Kamal Mostafa
2012-01-10 20:20 ` Eric Sandeen
2012-01-10 21:31 ` Jan Kara
2012-01-10 21:55 ` Surbhi Palande
[not found] ` <CAMBkX3eVeKSmEzmYTe6Oe_D6kAMQTL5LYoi1-Axj7CcrM85Pow@mail.gmail.com>
2012-01-11 0:04 ` Jan Kara
2012-01-11 0:13 ` Surbhi Palande
2012-01-11 0:51 ` Jan Kara
2012-01-11 0:51 ` Jan Kara
2012-01-11 5:38 ` Surbhi Palande
2012-01-11 6:06 ` Surbhi Palande
2012-01-11 12:10 ` Jan Kara
2012-01-11 16:45 ` Surbhi Palande
2012-01-11 18:13 ` Jan Kara
2012-01-11 3:08 ` Eric Sandeen [this message]
2012-01-10 22:00 ` Surbhi Palande
2012-01-10 22:00 ` Surbhi Palande
2011-12-08 18:04 ` [PATCH v2 2/7] Freeze and thaw the journal on ext4 freeze Kamal Mostafa
2012-01-06 0:32 ` Jan Kara
2011-12-08 18:04 ` [PATCH v2 3/7] VFS: Fix s_umount thaw/write deadlock Kamal Mostafa
2012-01-06 1:50 ` Jan Kara
2011-12-08 18:04 ` [PATCH v2 4/7] VFS: Rename and refactor writeback_inodes_sb_if_idle Kamal Mostafa
2011-12-13 3:34 ` Miao Xie
2011-12-15 7:10 ` Miao Xie
2011-12-16 20:48 ` Kamal Mostafa
2012-01-06 0:33 ` Jan Kara
2011-12-08 18:04 ` [PATCH v2 5/7] VFS: Avoid read-write deadlock in try_to_writeback_inodes_sb Kamal Mostafa
2012-01-06 0:35 ` Jan Kara
2012-01-11 20:29 ` Kamal Mostafa
2012-01-12 15:53 ` Mikulas Patocka
2011-12-08 18:04 ` [PATCH v2 6/7] VFS: Document s_frozen state through freeze_super Kamal Mostafa
2012-01-06 0:36 ` Jan Kara
2011-12-08 18:04 ` [PATCH v2 7/7] Documentation: Correct s_umount state for freeze_fs/unfreeze_fs Kamal Mostafa
2012-01-06 0:36 ` Jan Kara
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=4F0CFD2B.7010404@redhat.com \
--to=sandeen@redhat.com \
--cc=adilger.kernel@dilger.ca \
--cc=christopher.chaltain@canonical.com \
--cc=csurbhi@gmail.com \
--cc=jack@suse.cz \
--cc=kamal@canonical.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=mpatocka@redhat.com \
--cc=peter.petrakis@canonical.com \
--cc=rdunlap@xenotime.net \
--cc=sandeen@sandeen.net \
--cc=surbhi.palande@canonical.com \
--cc=tytso@mit.edu \
--cc=val@vaaconsulting.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.