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.
