[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4C56C461.8020207@gmail.com>
Date: Mon, 02 Aug 2010 15:13:05 +0200
From: Edward Shishkin <edward.shishkin@...il.com>
To: Nick Piggin <npiggin@...e.de>
CC: Christian Stroetmann <stroetmann@...olinux.com>,
Glenn D <doiggl@...ocitynet.com.au>,
linux-kernel <linux-kernel@...r.kernel.org>,
linux reiserfs-devel <reiserfs-devel@...r.kernel.org>
Subject: Re: Formal Reiser4 inclusion and todo list?
Nick Piggin wrote:
> On Sun, Aug 01, 2010 at 03:43:05PM +0200, Christian Stroetmann wrote:
>
>> Hi Glenn;
>>
>> On the 28.07.2010 21:58, I wrote:
>>
>>> Aloha Glenn;
>>>
>>> At the 28.07.2010 17:21, you (doiggl@...ocitynet.com.au) wrote:
>>>
>>>>> The following items are still unaddressed:
>>>>>
>>>>> 1. running igrab() in the writepage() path is really going to hammer
>>>>> inode_lock. Something else will need to be done here.
>>>>>
>>>>> 2. Running iput() in entd() is a bit surprising. iirc there
>>>>> are various
>>>>> ways
>>>>> in which this can recur into the filesystem, perform I/O, etc. I
>>>>> guess it
>>>>> works..
>>>>> But again, it will hammer inode_lock.
>>>>>
>
> inode_lock should be going away within 6 months or so, with the
> vfs-scaling developments (see linux-fsdevel).
>
Yup, I keep a track of your efforts,
it would be nice..
> Inode refcounting becomes very light-weight, as it should be.
>
>
>
>>>>> 3. the writeout logic in entd_flush() is interesting (as in
>>>>> "holy cow").
>>>>> It's very central and really needs some good comments describing
>>>>>
>>>> what's
>>>>
>>>>> going on in there - what problems are being solved, which decisions
>>>>>
>>>> were
>>>>
>>>>> taken and why, etc.
>>>>>
>>>>> 4. reiser4_wait_page_writeback() needs commenting.
>>>>>
>>>>> 5. reading the comment in txnmgr.c regarding MAP_SHARED pages: a number
>>>>>
>>>> of
>>>>
>>>>> things have changed since then. We have page-becoming-writeable
>>>>> notifications and probably soon we'll always take a
>>>>> pagefault when a
>>>>> MAP_SHARED page transitions from pte-clean to pte-dirty (although I
>>>>> wouldn't
>>>>> recommend that a filesystem rely upon the latter for a while yet).
>>>>>
>
> It is now possible to trap all dirtying activity from all sources
> except get_user_pages (but filesystems tend to ignore that little
> problem).
>
Thanks for looking at this.
Edward.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists