I agree, reiser4 has been very slow for me, and as I've upgraded the kernel,
it's gotten, if anything, worse.
I'm currently running 2.6.18-mm3. I upgraded (as I have before) in the hope
that the generally very slow issue had been fixed in this kernel release,
and if I knew that it was fixed in the latest mm, I would upgrade in a
heartbeat.
I'd like to see this fixed, as it's the only real issue that I have. Is this
something that can be fixed in a reasonable time, or am I SOL and it's time
to switch back to ext3? Have money problems/Han's arrest stopped development?
I would think with a 1Ghz K7, I would have a fast enough processor But I
don't. Read/write maxes processor usage. I have a regularly scheduled backup
that rsyncs with a ext3 disk on the same machine. It slows the machine to a
standstill, processor time is 90%+ system. And that's just reading. Forget
burning a CD/DVD in a reasonable time. Although now that I have 1Gig of
memory inseat of the 128Mb that I had before, I can CACHE the CD image and
write it out in a reasonable timeframe. But accessing the disk is SLOW.
I disabled fsync in the kernel, and that helped some, but not that much.
I've had Reiser4 as my root file system for a number of years now, but I've
just about given up. I lust after the advanced features, encryption and
change logging in particular, but without a reasonably fast filesystem, I
don't see the point.
On Wednesday 24 January 2007 17:57, Xu CanHao wrote:
AFAIK, vim fsyncs, azureus fsyncs, and may be many other applications
fsyncs but not only databases.
Definitly turn off fsync() is a bad idea. I just wonder how bad r4's
fsync() performance is.
It seems the result is: disabled fsync() r4 is even slower than
enabled fsync() ext3.o
Is it never be possible to improve that? I found in the mailing-list
that Hans talked it for many years. this must be a CRITICAL
performance flaw for r4.
2007/1/25, [EMAIL PROTECTED] [EMAIL PROTECTED]:
On Wed, 24 Jan 2007 22:05:53 +0800, Xu CanHao said:
extremely low performance, i managed to turn off fsync() in
fs/reiser4/plugin/file/file.c (nullify the sync_unix_file() function),
(Maybe you understand the following, if so, feel free to ignore. I'm
mostly making sure the list archives have this note so anybody else
tempted to do this will think twice)...
Note that this can be *very* dangerous to the health of your database
if you implement it blindly without understanding the *full*
implications.
Basically, applications almost never call fsync() unless they need it for
database consistency. A system crash at an inopportune time *will*
totally ruin your database.
