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.
