[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <B11A8487-AA73-40DB-81C8-163006369077@redhat.com>
Date: Wed, 18 May 2011 12:40:44 -0400 (EDT)
From: Eric Sandeen <esandeen@...hat.com>
To: Jan Kara <jack@...e.cz>
Cc: Eric Sandeen <sandeen@...hat.com>,
Christoph Hellwig <hch@...radead.org>, Jan Kara <jack@...e.cz>,
Ted Tso <tytso@....edu>,
"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH 3/3] ext4: Block mmapped writes while the fs is frozen
On May 18, 2011, at 10:25 AM, Jan Kara <jack@...e.cz> wrote:
> On Wed 18-05-11 09:03:27, Eric Sandeen wrote:
>> On 5/18/11 3:07 AM, Christoph Hellwig wrote:
>>> On Wed, May 18, 2011 at 09:56:14AM +0200, Jan Kara wrote:
>>>> __block_page_mkwrite() and return some error value (EAGAIN translating to
>>>> VM_FAULT_RETRY would look logical, I just have to think off better error
>>>> value for VM_FAULT_NOPAGE). But vfs_check_frozen() cannot be in
>>>> __block_page_mkwrite() since ext4 needs to call that with a transaction
>>>> started so that would create a deadlock and we need to call
>>>> vfs_check_frozen() somewhere so that we don't busyloop.
>>>>
>>>> I can call vfs_check_frozen() inside block_page_mkwrite() but it would be a
>>>> bit surprising difference from __block_page_mkwrite() to me. Not sure what
>>>> the cleanest solution would be here...
>>>
>>> block_page_mkwrite is supposed to be used directly by filesystems and
>>> do all the right things. IIRC Eric even mentioned he added
>>> vfs_check_frozen to it for RHEL, but forgot to push it upstream.
>>
>> Well, I tried, but it was rejected IIRC. Still, mea culpa....
>>
>> I can resurrect what I did for RHEL5 and repost if desired...
> I've just submitted second version of the patch series. So please check
> whether it does all you need... Thanks.
>
Thanks! Btw the rejection I mentioned was years ago... Not you :)
-Eric
> Honza
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists