Hi!
I am possibly interested in helping out. Who is currently working on
reiser4? I took a look at the TODO lists, are there any simple tasks to
do for newbies?
Also, where is the latest code development going on?
I also believe that on 'sync', reiser4 currently does absolutely
nothing. The comment in reiser4_sync_inodes says reiser4 does its own
flush elsewhere. Should this be different?
Cheers,
Johannes
--
Emails k?nnen ge?ndert, gef?lscht und eingesehen werden. Signiere oder
versch?ssele deine Mails mit GPG.
Johannes Buchner wrote:
> Hi!
>
> I am possibly interested in helping out. Who is currently working on
> reiser4?
Nobody.
Because there is no bugreports.
> I took a look at the TODO lists, are there any simple tasks to
> do for newbies?
>
If you mean the "todo for inclusion", then no.
Reiser4 has only one technical issue. It can
be resolved only by very experienced people.
> Also, where is the latest code development going on?
>
in -mm
> I also believe that on 'sync', reiser4 currently does absolutely
> nothing.
this is not good: a file system should respond on sync (1).
> The comment in reiser4_sync_inodes says reiser4 does its own
> flush elsewhere. Should this be different?
>
you might want to ask such question _before_ sending patches to akpm.
BTW excellent comment, what is not clear?
/**
* reiser4_sync_inodes - sync_inodes of super operations
* @super:
* @wbc:
*
* This method is called by background and non-backgound writeback.
Reiser4's
* implementation uses generic_sync_sb_inodes to call reiser4_writepages for
* each of dirty inodes. Reiser4_writepages handles pages dirtied via shared
* mapping - dirty pages get into atoms. Writeout is called to flush some
* atoms.
*/
Edward.
On Wed, 02 Dec 2009 10:21:18 +0100
Edward Shishkin <[email protected]> wrote:
> Johannes Buchner wrote:
> > I took a look at the TODO lists, are there any simple tasks to
> > do for newbies?
>
> If you mean the "todo for inclusion", then no.
>
> Reiser4 has only one technical issue. It can
> be resolved only by very experienced people.
Thanks for replying. I did not have to the inclusion of
reiser4 in mind specifically.
> > I also believe that on 'sync', reiser4 currently does absolutely
> > nothing.
>
> this is not good: a file system should respond on sync (1).
>
> > The comment in reiser4_sync_inodes says reiser4 does its own
> > flush elsewhere. Should this be different?
> >
>
> you might want to ask such question _before_ sending patches to akpm.
I was under the believe that I did not change the behaviour. I see my
mistake now, I was looking at the wrong if-branch.
I tried now to come up with a correct version for some hours, but I keep
having NULL problems. Maybe a writeback_control object has to be
created, possibly even in fs/fs-writeback.c:sync_inodes_sb, as
write_inode_now does below. I tried that too, but it gave me a
recursion. I'm not sure what the rationale was for introducing a call
with NULL here. Sorry I can't correct this.
Looking forward to your review.
Best wishes,
Johannes
--
Emails k?nnen ge?ndert, gef?lscht und eingesehen werden. Signiere oder
versch?ssele deine Mails mit GPG.
Johannes Buchner wrote:
> On Wed, 02 Dec 2009 10:21:18 +0100
> Edward Shishkin <[email protected]> wrote:
>
>
>> Johannes Buchner wrote:
>>
Hello.
>>> I took a look at the TODO lists, are there any simple tasks to
>>> do for newbies?
>>>
>> If you mean the "todo for inclusion", then no.
>>
>> Reiser4 has only one technical issue. It can
>> be resolved only by very experienced people.
>>
>
> Thanks for replying. I did not have to the inclusion of
> reiser4 in mind specifically.
>
>
>>> I also believe that on 'sync', reiser4 currently does absolutely
>>> nothing.
>>>
>> this is not good: a file system should respond on sync (1).
>>
>>
>>> The comment in reiser4_sync_inodes says reiser4 does its own
>>> flush elsewhere. Should this be different?
>>>
>>>
>> you might want to ask such question _before_ sending patches to akpm.
>>
>
> I was under the believe that I did not change the behaviour. I see my
> mistake now, I was looking at the wrong if-branch.
>
Nop. You've lost the whole point of using of ->sync_inodes(), which is
responsible for reiser4 background (and non-background) writeback,
and now it is not involved by any path.
Here is a good explanation why we need this additional super operation:
http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm1/broken-out/reiser4-sb_sync_inodes.patch
> I tried now to come up with a correct version for some hours, but I keep
> having NULL problems. Maybe a writeback_control object has to be
> created, possibly even in fs/fs-writeback.c:sync_inodes_sb, as
> write_inode_now does below. I tried that too, but it gave me a
> recursion.
It may happens because of missed checks that a process is of pdflush-style.
Perhaps, we need to rename the current_is_pdflush() and get it back.
Thanks,
Edward.
> I'm not sure what the rationale was for introducing a call
> with NULL here. Sorry I can't correct this.
>
> Looking forward to your review.
>
> Best wishes,
> Johannes
>
>