Re: More Slowdown

["Artur Makówka" <juice@ursynow.2a.pl>]

Hans Reiser wrote:
> fsync can be dramatically better optimized, and it will be after the
> kernel merge work is completed.  This optimization will likely consist
> of reducing the tendency to merge atoms and handling fsync by using
> write twice algorithms to a fixed journal area.  Other improvements will
> doubtless be found when time is spent on it.  I am sorry that vim and
> evolution are suffering so much from our neglecting fsync until after
> the merge.  fsync is one of the things I would have us working on if I
> had my choice of what we improved in reiser4 rather than other persons
> making that choice for us at the moment.  Oh well, such is life in the
> society of men.;-)
> 
> It looks like akpm is going to start reading the reiser4 code.  I
> suspect his remarks will be a step above the ones made so far, he wrote
> such nice readahead code.
> 

Just want to add, that for desktop systems its only vim and evolution, 
but for my free hosting server it was very frequent system crashes 
(because of that i lost part of my database) and so on. Just want to 
warn anyone deciding to use reiser4 on server, to use 2.6.12 kernels or 
lower as this bug is almost not existent there.

For some uses of reiser4 this bug is very dangerous. Not just slow work 
of some application, but like i said data loss, system instability (few 
crashes every day), and so on.

I would say such a bug/design choice should be top priority, number one. 
Of course thats not true if reiser4 is meant to be only for home use. 
Just want to point that out, because it seems everybody is using reiser4 
only at home, and i am the only one on earth using it on server 
environment (i guess that wasn't the best idea...)

Thanks in advance for consideration of taking this bug to top of your 
TODO list.