Re: kernel BUG at fs/reiser4/plugin/item/ctail.c

Re: kernel BUG at fs/reiser4/plugin/item/ctail.c

[Edward Shishkin]

Mr. Tao wrote:
> I just wanted to add sample of fsck failure:
>
> [103a3:2e4368616e6765:3ce4f] (ccreg40), node [721], item [10]: item of the wrong
> cluster size (-2147483648) found, Should be (65536).
> zsh: segmentation fault  fsck.reiser4 /dev/sda8
>
>   

Note, that data of logical cluster #249423 of the file (inode 66467) are
lost.
Maybe It makes sense to replace this file (it can be found, for example,
with "find -inum 66467") with a correct one..

Edward.

Re: kernel BUG at fs/reiser4/plugin/item/ctail.c

[Dushan Tcholich]

Would it be possible if there would be a new version of fsck.reiser4
to fix those false positives about wrong size when checking
cryptocompress partitions?
There are some users that reported those and it's not comforting when
your fs spews thousands of errors, even when someone tells you they're
false.

Oh and what about making cryptocompress default format on mkfs.reiser4 ?

Have a nice day
Dushan

Re: kernel BUG at fs/reiser4/plugin/item/ctail.c

[Edward Shishkin]

Dushan Tcholich wrote:
> Would it be possible if there would be a new version of fsck.reiser4
> to fix those false positives about wrong size when checking
> cryptocompress partitions?
>   

Yes,  per-file warnings about wrong i_bytes should be suppressed.
Fsck just should report at the end of work in default mode, that N wrong
i_bytes were detected and suggest to fix it with --fix option.
Anyone care to try to make a patch?

> There are some users that reported those and it's not comforting when
> your fs spews thousands of errors, even when someone tells you they're
> false.
>
> Oh and what about making cryptocompress default format on mkfs.reiser4 ?
>   

mm.. not sure. First, fsck should be fixed to remove unprepped items.
Mr. Tao, do you still have partitions that make fsck segfault?

Thanks,
Edward.

Re: kernel BUG at fs/reiser4/plugin/item/ctail.c

[Dushan Tcholich]

On Mon, Aug 4, 2008 at 4:47 PM, Edward Shishkin
<edward.shishkin@gmail.com> wrote:
> Dushan Tcholich wrote:
>> Would it be possible if there would be a new version of fsck.reiser4
>> to fix those false positives about wrong size when checking
>> cryptocompress partitions?
>>
>
> Yes,  per-file warnings about wrong i_bytes should be suppressed.
> Fsck just should report at the end of work in default mode, that N wrong
> i_bytes were detected and suggest to fix it with --fix option.
> Anyone care to try to make a patch?
>
But what happens with systems with ccreg and fsck on boot? They would
stop and wait for user interaction.
Or you meant just to print a message about it with recomended solution
and continue.

I'd like to make a patch but dunno how :)

>> There are some users that reported those and it's not comforting when
>> your fs spews thousands of errors, even when someone tells you they're
>> false.
>>
>> Oh and what about making cryptocompress default format on mkfs.reiser4 ?
>>
>
> mm.. not sure. First, fsck should be fixed to remove unprepped items.
Ofcourse.

> Mr. Tao, do you still have partitions that make fsck segfault?
>
> Thanks,
> Edward.
>
Dushan

Re: kernel BUG at fs/reiser4/plugin/item/ctail.c

[Edward Shishkin]

Dushan Tcholich wrote:
> On Mon, Aug 4, 2008 at 4:47 PM, Edward Shishkin
> <edward.shishkin@gmail.com> wrote:
>   
>> Dushan Tcholich wrote:
>>     
>>> Would it be possible if there would be a new version of fsck.reiser4
>>> to fix those false positives about wrong size when checking
>>> cryptocompress partitions?
>>>
>>>       
>> Yes,  per-file warnings about wrong i_bytes should be suppressed.
>> Fsck just should report at the end of work in default mode, that N wrong
>> i_bytes were detected and suggest to fix it with --fix option.
>> Anyone care to try to make a patch?
>>
>>     
> But what happens with systems with ccreg and fsck on boot? They would
> stop and wait for user interaction.
>   

Why?
Do you have any problems with boot?

> Or you meant just to print a message about it with recomended solution
> and continue.
>   

Everything should be the same except per-file warnings.

> I'd like to make a patch but dunno how :)
>
>   
>>> There are some users that reported those and it's not comforting when
>>> your fs spews thousands of errors, even when someone tells you they're
>>> false.
>>>
>>> Oh and what about making cryptocompress default format on mkfs.reiser4 ?
>>>
>>>       
>> mm.. not sure. First, fsck should be fixed to remove unprepped items.
>>     
> Ofcourse.
>
>   
>> Mr. Tao, do you still have partitions that make fsck segfault?
>>
>> Thanks,
>> Edward.
>>
>>     
> Dushan
>
>   

Re: kernel BUG at fs/reiser4/plugin/item/ctail.c

[Dushan Tcholich]

On Mon, Aug 4, 2008 at 6:50 PM, Edward Shishkin
<edward.shishkin@gmail.com> wrote:
> Dushan Tcholich wrote:
>> On Mon, Aug 4, 2008 at 4:47 PM, Edward Shishkin
>> <edward.shishkin@gmail.com> wrote:
>>
>>> Dushan Tcholich wrote:
>>>
>>>> Would it be possible if there would be a new version of fsck.reiser4
>>>> to fix those false positives about wrong size when checking
>>>> cryptocompress partitions?
>>>>
>>>>
>>> Yes,  per-file warnings about wrong i_bytes should be suppressed.
>>> Fsck just should report at the end of work in default mode, that N wrong
>>> i_bytes were detected and suggest to fix it with --fix option.
>>> Anyone care to try to make a patch?
>>>
>>>
>> But what happens with systems with ccreg and fsck on boot? They would
>> stop and wait for user interaction.
>>
>
> Why?
> Do you have any problems with boot?

I don't have problems.
I just thought that checking for these false positives lasted 10
minutes on my 6GB / so wouldn't this be a little too long if we don't
put some status of some sorts?

>> Or you meant just to print a message about it with recomended solution
>> and continue.
>>
>
> Everything should be the same except per-file warnings.
>
Maybe a better explanation would be better instead just: "600000 small
errors found" :)

>> I'd like to make a patch but dunno how :)
>>
>>
>>>> There are some users that reported those and it's not comforting when
>>>> your fs spews thousands of errors, even when someone tells you they're
>>>> false.
>>>>
>>>> Oh and what about making cryptocompress default format on mkfs.reiser4 ?
>>>>
>>>>
>>> mm.. not sure. First, fsck should be fixed to remove unprepped items.
>>>
>> Ofcourse.
>>
>>
>>> Mr. Tao, do you still have partitions that make fsck segfault?
>>>
>>> Thanks,
>>> Edward.
>>>
>>>
>> Dushan
>>
>>
>
>

Re: kernel BUG at fs/reiser4/plugin/item/ctail.c

[Volker Armin Hemmann]

On Montag, 4. August 2008, Dushan Tcholich wrote:
> On Mon, Aug 4, 2008 at 6:50 PM, Edward Shishkin
>
> <edward.shishkin@gmail.com> wrote:
> > Dushan Tcholich wrote:
> >> On Mon, Aug 4, 2008 at 4:47 PM, Edward Shishkin
> >>
> >> <edward.shishkin@gmail.com> wrote:
> >>> Dushan Tcholich wrote:
> >>>> Would it be possible if there would be a new version of fsck.reiser4
> >>>> to fix those false positives about wrong size when checking
> >>>> cryptocompress partitions?
> >>>
> >>> Yes,  per-file warnings about wrong i_bytes should be suppressed.
> >>> Fsck just should report at the end of work in default mode, that N
> >>> wrong i_bytes were detected and suggest to fix it with --fix option.
> >>> Anyone care to try to make a patch?
> >>
> >> But what happens with systems with ccreg and fsck on boot? They would
> >> stop and wait for user interaction.
> >
> > Why?
> > Do you have any problems with boot?
>
> I don't have problems.
> I just thought that checking for these false positives lasted 10
> minutes on my 6GB / so wouldn't this be a little too long if we don't
> put some status of some sorts?
>
> >> Or you meant just to print a message about it with recomended solution
> >> and continue.
> >
> > Everything should be the same except per-file warnings.
>
> Maybe a better explanation would be better instead just: "600000 small
> errors found" :)
>

that would completly freak out people. How about '60000 false file sizes - 
this is normal with compression'?

Re: kernel BUG at fs/reiser4/plugin/item/ctail.c

[Edward Shishkin]

Volker Armin Hemmann wrote:
> On Montag, 4. August 2008, Dushan Tcholich wrote:
>   
>> On Mon, Aug 4, 2008 at 6:50 PM, Edward Shishkin
>>
>> <edward.shishkin@gmail.com> wrote:
>>     
>>> Dushan Tcholich wrote:
>>>       
>>>> On Mon, Aug 4, 2008 at 4:47 PM, Edward Shishkin
>>>>
>>>> <edward.shishkin@gmail.com> wrote:
>>>>         
>>>>> Dushan Tcholich wrote:
>>>>>           
>>>>>> Would it be possible if there would be a new version of fsck.reiser4
>>>>>> to fix those false positives about wrong size when checking
>>>>>> cryptocompress partitions?
>>>>>>             
>>>>> Yes,  per-file warnings about wrong i_bytes should be suppressed.
>>>>> Fsck just should report at the end of work in default mode, that N
>>>>> wrong i_bytes were detected and suggest to fix it with --fix option.
>>>>> Anyone care to try to make a patch?
>>>>>           
>>>> But what happens with systems with ccreg and fsck on boot? They would
>>>> stop and wait for user interaction.
>>>>         
>>> Why?
>>> Do you have any problems with boot?
>>>       
>> I don't have problems.
>> I just thought that checking for these false positives lasted 10
>> minutes on my 6GB / so wouldn't this be a little too long if we don't
>> put some status of some sorts?
>>
>>     
>>>> Or you meant just to print a message about it with recomended solution
>>>> and continue.
>>>>         
>>> Everything should be the same except per-file warnings.
>>>       
>> Maybe a better explanation would be better instead just: "600000 small
>> errors found" :)
>>
>>     
>
>   

There is no big problem here:

Kernel:
-----------
For unix-file plugin:
(1) set i_size and real size which coincide with each other;
(2) don't protect data by checksums (for performance reasons).

For cryptcompress plugin:
(1) set  i_size which usually doesn't coincide with real size;
(2) don' t set real size for performance issues.
(3) set data checksums for every logical cluster;

Fsck:
----------
I. For unix-file plugin:
(1) check if i_size == real size, if no then
     (a) report error and
     (b) handle as corruption

II. For cryptcompress plugin:
(1) check checksums; If wrong, then handle as corruption;
(2) check if i_size == real size, if no, then
     (a) report error;
     (b) set correct real size;

It is clear, that (II.2.a) is not needed. Just because (II.1): checksums is
the best means to detect corruptions.

> that would completly freak out people. How about '60000 false file sizes - 
> this is normal with compression'?
> --
> 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
>
>   

Re: kernel BUG at fs/reiser4/plugin/item/ctail.c

[Mr. Tao]

> >>> Dushan Tcholich wrote:
> >>
> >>
> >>> Mr. Tao, do you still have partitions that make fsck segfault?
> >>>
No, sorry, (un)fortunatelly not any more. These errors occured when fscking portage and ccache partitions, which I decided to put in separate disk partitions, so I used mkfs.reiser4 to "correct" them. (In the past I had them as uncompressible loop files on root reiser4 CC partition, but this _always_ (and I've tried a lot of times with different kernels) led to fatal corruption of root fs --> *loop files on R4 is no go* solution).  I also had them as part of root FS, but this approach was also futile and led to corruption of / FS. Seems like (at least at thouse times) R4 couldn't handle very well heavy load, as there are moments with gentoo, where both ccache and portage are under stress.

[reiser4] Point

[Ryan Hope]

Is this todo really done?

 >> 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.

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);

Re: [reiser4] Point

[Edward Shishkin]

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
>

Re: [reiser4] Point

[Ryan Hope]

This works because the struct "ent" is of type "entd_context" 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.

-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
>>
>
>

Re: [reiser4] Point

[Edward Shishkin]

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
>>>
>>>       
>>     
>
>   

Re: [reiser4] Point

[Matthew]

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 ...

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
>

Re: [reiser4] Point

[Edward Shishkin]

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
>>
>>     
>
>   

Re: [reiser4] Point

[Matthew]

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 ?

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
- *

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
>>>
>>>
>>
>>
>
>

Re: [reiser4] Point

[Edward Shishkin]

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
>>>>
>>>>
>>>>         
>>>       
>>     
>
>   

Re: [reiser4] Point

[Ryan Hope]

With just that first patch this is how I was stress-testing it....

My rootfs is ext3 and my /usr/portage partition is reiser4...

I did this: 'cd /usr/portage; while (true); do bonnie; done'
Then on another console I ran 'emerge glibc'
On another console I ran 'emerge --sync'
On another console I compiled my kernel

I did not do any benchmarks, just looked in dmesg for anything abnormal.

-Ryan

On Wed, Aug 13, 2008 at 5:57 AM, Edward Shishkin
<edward.shishkin@gmail.com> wrote:
> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
>

Re: [reiser4] Point

[Alli Quaknaa]

Correct me if I'm wrong, but the "emerge glibc" and compiling kernel
are not actually happening on the reiser4 partition (if it is
/usr/portage only) and they IMHO actually lower the stress on the
reiser4 partition, because they consume CPU power that would be used
by emerge sync and bonnie (which do stress-test the reiser4
partition).

But maybe I'm wrong, or it was the point to get emerge sync & bonnie
working in an environment where they have to compete for CPU time with
other processes?

(Please bear with me, I'm not a developer and I'm newbie, but I use
Gentoo so the things above seemed weird to me).
al-Quaknaa

Re: [reiser4] Point

[Ryan Hope]

Well bonnie is running on the reiser4 partition and so is emerge
--sync.... I figured a better stress of reiser4 would be to see how it
hold up when the whole system is loaded as well, not just reiser4
working alone

On Wed, Aug 13, 2008 at 11:59 AM, Alli Quaknaa <alquaknaa@gmail.com> wrote:
> Correct me if I'm wrong, but the "emerge glibc" and compiling kernel
> are not actually happening on the reiser4 partition (if it is
> /usr/portage only) and they IMHO actually lower the stress on the
> reiser4 partition, because they consume CPU power that would be used
> by emerge sync and bonnie (which do stress-test the reiser4
> partition).
>
> But maybe I'm wrong, or it was the point to get emerge sync & bonnie
> working in an environment where they have to compete for CPU time with
> other processes?
>
> (Please bear with me, I'm not a developer and I'm newbie, but I use
> Gentoo so the things above seemed weird to me).
> al-Quaknaa
>

Re: [reiser4] Point

[Alli Quaknaa]

OK, I wasn't sure if it was intended this way.

Anyway - I've just got a new notebook and I'm putting my / on reiser4
and I've already got to a little trouble, when I tried to kill some
processes and the kill didn't work, and dmesg reported some oops. I
know this isn't very useful (cause I don't have the oops or other
specific info), I just want to point out that there will probabyl be a
higher number of problematic situations for teh fs to handle on / than
anywhere else. I will report whatever is to come and I will try to
help with testing as much as possible :)

Thanks for the great fs you're working on :)
al-Quaknaa