Re: [reiser4] Point

[Edward Shishkin <edward.shishkin@gmail.com>]

Matthew wrote:
> Hi Edward,
>
> ok, I'm testing it (patch 1) on my production system since yesterday,
> no adverse effects until now,
>
> could you please explain what you exactly mean with "stress test"?
> which loads does it include ?
>
>   

It means regression testing with any set of applications
that involves as much file api as possible and causes
intensive IO activity.

> I'm using this for the following tasks right now:
> - syncing the portage-tree (lots of small files, at least once a day;
> a separate reiser4-partition for /usr/portage)
> - emerging applications (reiser4 on the system-partition; emerge &
> compilations put relative heavy load on it)
> - creating stage4-tarballs (creating a tarball out of the running system)
> - heavy compiling kernels (with -j 25)
> - usual daily "work" (booting into the OS & launching / working with apps)
> - updatedb
> - *
>
>   

Ok, its enough.
Thanks to everyone!

> if you need more tasks to do let me know and I'll try to include them
>
> Thanks
>
> Mat
>
> On Tue, Aug 12, 2008 at 10:47 PM, Edward Shishkin
> <edward.shishkin@gmail.com> wrote:
>   
>> Matthew wrote:
>>     
>>> Hi Edward,
>>>
>>> I somehow did kind of a stress-test to it (all of those patches):
>>> usual file operations were comparable (compared to the unpatched
>>> reiser4-tree), but (f)sync-"performance" was somehow abysmal:
>>>
>>> whereas it would take 2-5 minutes for the default reiser4 to sync data
>>> out to disk after a kernel-compilation (issueing 'time sync'), it
>>> would take >40+ minutes for the patched version to do so, also the hdd
>>> would be clattering all the time during that
>>>
>>> in following cases it would take significant longer:
>>> - emergency syncing [with magic sysrq key]
>>> - emergency remount (sometimes it wouldn't even finish)
>>> - parallel tasks (doing more things at a time / launching several apps at once)
>>> - hdparm -t /dev/sda (seemingly cache-flushing, heavy clattering
>>> before & after the output)
>>> - sync
>>> - shutdown -h now, reboot
>>>
>>> here's the page of the thread where I posted all of the testing-experience:
>>> http://forums.gentoo.org/viewtopic-t-696253-start-375.html
>>>
>>> could it be that Ryan's problems with ext3/ext4 are caused by probable
>>> inherent problems / bugs with them than rather being a bug in reiser4
>>> itself ?
>>>
>>> I don't have any partition with ext* filesystems, only reiserfs +
>>> reiser4 and unfortunately  also can't reproduce this behavior ...
>>>
>>>
>>>       
>> Guys, patches 2/3, 3/3 of the latest series are wrong and all
>> manipulations with this stuff (testing, getting stacktraces, etc.)
>> is just useless wasting your time.
>>
>> The patch 1/3 (use-wake_up_process-instead-of-wake_up)
>> seems to be ok, but it must be stress tested.
>> If there are any problems specific to this patch, then let me know.
>>
>> Thanks,
>> Edward.
>>
>>     
>>> the reiser4-devel/reiser4 testing-tree (for zen) can be found on the
>>> zen-sources git-server:
>>> http://zen-sources.org/cgi-bin/gitweb.cgi?p=kernel.git;a=summary
>>> kudos to Ryan, Miguel, Dominic and Corbin :)
>>>
>>> keep up the work, guys ! :)
>>>
>>> Thanks
>>>
>>> Mat
>>>
>>> On Tue, Aug 12, 2008 at 8:58 PM, Edward Shishkin
>>> <edward.shishkin@gmail.com> wrote:
>>>
>>>       
>>>> Ryan Hope wrote:
>>>>
>>>>         
>>>>> This works because the struct "ent" is of type "entd_context"
>>>>>
>>>>>           
>>>> This logic train goes to a wrong direction ;)
>>>>
>>>>
>>>>         
>>>>>  which
>>>>> has members "wait_queue_head_t wait" and "struct task_struct *tsk".
>>>>> The function wake_up() takes the parameter wait_queue_head_t the
>>>>> function wake_up_process() takes task_struct... I figured this would
>>>>> be a legit switch. I have seen no adverse affects yet.
>>>>>
>>>>>
>>>>>           
>>>> Did you stress test it?
>>>>
>>>> Thanks,
>>>> Edward.
>>>>
>>>>
>>>>         
>>>>> -Ryan
>>>>>
>>>>> On Fri, Aug 8, 2008 at 4:47 PM, Edward Shishkin
>>>>> <edward.shishkin@gmail.com> wrote:
>>>>>
>>>>>
>>>>>           
>>>>>> Ryan Hope wrote:
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> Is this todo really done?
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>> nop
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>>>>>> As in point 6. in todo list (pub.namesys.com/Reiser4/ToDo ) try to
>>>>>>>>> replace wake_up() with wake_up_process()
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                   
>>>>>>> There are still a few more wake_up()'s in the code, the following
>>>>>>> patch takes care of 2 of them.
>>>>>>>
>>>>>>>
>>>>>>>               
>>>>>>  both are not obvious for me, review is needed..
>>>>>>
>>>>>> Edward.
>>>>>>
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> diff --git a/fs/reiser4/entd.c b/fs/reiser4/entd.c
>>>>>>> index a164f5a..355548d 100644
>>>>>>> --- a/fs/reiser4/entd.c
>>>>>>> +++ b/fs/reiser4/entd.c
>>>>>>> @@ -218,7 +218,7 @@ void reiser4_leave_flush(struct super_block *super)
>>>>>>>  #endif
>>>>>>>      spin_unlock(&ent->guard);
>>>>>>>      if (wake_up_ent)
>>>>>>> -        wake_up(&ent->wait);
>>>>>>> +        wake_up_process(ent->tsk);
>>>>>>>  }
>>>>>>>
>>>>>>>  #define ENTD_CAPTURE_APAGE_BURST SWAP_CLUSTER_MAX
>>>>>>> @@ -304,7 +304,7 @@ int write_page_by_ent(struct page *page, struct
>>>>>>> writeback_control *wbc)
>>>>>>>      ent->nr_todo_reqs++;
>>>>>>>      list_add_tail(&rq.link, &ent->todo_list);
>>>>>>>      if (ent->nr_todo_reqs == 1)
>>>>>>> -        wake_up(&ent->wait);
>>>>>>> +        wake_up_process(ent->tsk);
>>>>>>>
>>>>>>>      spin_unlock(&ent->guard);
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>>> reiserfs-devel" in
>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>
>>>>
>>>>         
>>>       
>>     
>
>