Reiser4 Benchmarks 414
A user writes "Hans Reiser has benchmarked Reiser4 against ext3 and Reiserfs 3. Reiser4 turns out to be way faster than V3, and for ext3, why don't you check out the results yourself ? Hans Reiser states, "these benchmarks mean to me that our performance is now good enough to ship V4 to users", and he will be probably sending in a patch within the next couple of weeks to be included in the 2.6/2.5 kernel."
It's really good that filesystems are maturing too (Score:2, Insightful)
wait! (Score:5, Insightful)
hey, I can live with an unstable gnome or Kicq, but a beta filesystem?? no thanks dude!
Reiser4? Competition? (Score:5, Insightful)
So how much better is this really? (Score:3, Insightful)
Would this increase the speed of a normal system by any noticable amount? Is it worth my time to switch over my EXT3 filesystem to reiser4? Are there programs that can perform the filesystem change for me?
I don't understand the statistics (Score:5, Insightful)
The comparisons are done with [foreign filesystem] divided by reiser4.
One would think that numbers greater than one, where the foreign filesystem has a long running time and reiser4 a short one, would be the ones that benefit reiser4.
Yet the numbers *less* than one are green, where Hans says reiser4 is considered better.
What's going on?
(Incidently, after having a friend lose a filesystem to buggy reiser code, I'm a bit inclined to wait until people have *seriously* hammered on this).
Bugs (Score:4, Insightful)
Re:Reliability (Score:5, Insightful)
The fact of the matter is, it is easier to make a fast system than a stable, reliable one.
Re:Which to choose for DBs? (Score:0, Insightful)
If I'm reading these right.... (Score:4, Insightful)
The first table with the mixed file sizes is the most compelling. The fact that reiser4's Create and Copy times are less than a third of the ext3s in real_time is impressive.
But the fact that the CPU consumption on Read is double that for R4 as it is for ext3 is a serious problem. On a 1.3 Ghz machine saturating a generic UDMA 100 60G bus on RH 9.0 it's about 10% of the CPU, so the home user might not care. For a system capable of delivering serious data (like a 4 drive, 15k rpm SCSI RAID array @~3 times the read throughput) going from 30% CPU to 60% CPU usage is a definite problem. Even with a 2.6 Ghz cpu it would still move from chewing up 15% to 30%. I know these numbers don't scale exactly, but they could in fact scale ugly depending on how much CPU is dedicated to communicating with the hardware and how much is in fiddling with the filesystem. My production boxes spend > 80% of their disk activity reading, so I'm not yet inspired to go out and spend the time running benchmarks on highperf. systems just yet.
Nevertheless, I always admire it when a new version of software comes out and it's noticeably faster than the old
Real comparison? (Score:4, Insightful)
That would be interesting.
Re:XFS? (Score:3, Insightful)
I'd also like to see it compared to JFS and maybe ext2 (if not just for reference).
Re:Reliability (Score:1, Insightful)
Nice.
Re:ReiserFS == BrokenFS (Score:1, Insightful)
Ever heard of the concept of evolution?
use Pavlovian Conditioning (Score:3, Insightful)
>
> I've found users doing that to my servers before now. I find
> that hitting them on the nose with a rolled up newspaper and
> shouting "No! Bad monkey!" in a stern voice tends to stop this
> behaviour...
Even better: configure the services that the users use so that
they don't start up at system start. Write a short script that
starts them all, and whenever you restart the server ssh in and
run it. That way, if users cold-reset the server, nothing will
work until you fix it anyway, so you might be able to break them
of that habbit then. (Otherwise, they'll just do it behind your
back and not tell you; this way, they HAVE to come to you.) The
only internet service that needs to start at system start in such
a setup is sshd, and with that you can start up everything else
from anywhere easily.
If you have any coworkers (or underlings) clueful enough to handle
a shell prompt, you can train them to ssh in and do a _proper_
restart, and tell them how to start up all the services by running
your start-services script.
One more option: you can disconnect the reset switch. However,
that won't stop them from just unplugging it, which I've found
myself doing to Win9x systems when the reset switch does nothing,
or on some Linux systems when shutdown -h doesn't turn off the
power when it's finished, if there's no real power switch other
than the on-only kind a lot of newer cases sport.
So, just fix it so that doing Bad Things (like power-cycling)
doesn't achieve perceived positive results.
Re:Warning (Score:5, Insightful)
It is important that you use a distro that bases their kernel on 2.4.18, or later, when using ReiserFS. There exists a distro that bases their enterprise server kernel on 2.4.9, and intentionally declines to add any reiserfs bugfixes since then. (This is the same distro that once shipped their kernel with the ReiserFS debugging code turned on so that we would go slow.) Do NOT use their kernel with ReiserFS. Generally when someone reports that they are having really bad experiences with ReiserFS, it turns out they are using that kernel.
I generally recommend using the latest official kernel from Marcelo, and not any distro kernels, but the SuSE kernels tend to have effective ReiserFS support also, and not everyone out there shares my non-technical preference for a common community developed kernel.
Re:Honest Portability Question (Score:2, Insightful)
And why would that be?
I don't see anything in the GPL that would prevent including ReiserFS with a BSD kernel.
Re:use Pavlovian Conditioning (Score:3, Insightful)
As for the "on only" power switches, most of the computers have bios settings for that, and if not, holding them down for about 4 seconds usually works.
Re:Reiser4? Competition? (Score:3, Insightful)
Dont get me wrong, reiserfs has impressive performance, but the recurring problems with bugs causing crashes when using reiserfs makes me extremely reluctant to use it on any production system.
A filesystem can have incredible performance, great features and impressive data consistency, but if it crashes the machine it's unusable.
Currently I dont see the developers of reiserfs paying nearly enough attention to stability, nor do they seem particularly interested in the subject, preferring features and performance over stability.
Laudable goals, but goals that puts the safe use of reiserfs into a small niche of high-performance failure tolerant systems.
Re:Filesystems for the laptop user? (Score:4, Insightful)
From the impression I have after having read the V4 design docs, in most cases it's a matter of just writing the new data without touching the old, then updating the bookkeeping entries and marking the old information as unneeded. In theory, this method gives journalling and crash safety "for free".
In practice, there's the matter of increased code complexity, which means that you'll take a hit on CPU usage, at least until the developers can stop their mad rush to get V4 into Linux 2.6 and work on code-level optimization (as opposed to optimizing the algorithms), but with Reiser's tree algorithms you're probably spinning the disk less while waiting for the filesystem code to find the data you need.
At any rate, full data journalling comes without the burden of "log what I'm going to do, complete with data, then perform the operations, then mark the pending operation as completed in the journal." Basically you get around having to write twice in nearly all cases.
(If ReiserFS decides that it's a really really good idea to leave the data where it's at, it will write new contents to free space on the disk, update the tree to reflect the changes, write the new contents to the original file's location on the disk, and again update the tree. However, this only occurs in rare circumstances, and is the exception rather than the norm.)
Re:Reiser4? Competition? (Score:5, Insightful)
XFS is probably one of the fastest journalling filesystems out there, all-round, and probably offers the best competition to Reiser4. I'm actually surprised not to see some benchmarks against it, as XFS has gathered quite a following in places.
The port of the Plan9 filing system is said to be one of the fastest filing systems out there - enough so that it's a part of a Government research program called "Pink", run by some mad scientists at Los Alamos. Yes, that Los Alamos. Again, this would be an excellent FS to have some benchmarks against.
Last, but not least, Reiser4 didn't do spectacularly well against Ext3 in the benchmarks. I saw plenty of results both ways. Reading vs. Deleting, for example, shows a definite penalty whichever FS you choose, depending on the operations you're performing.
In the end, if you truly want the fastest system, you should format partitions according to the type of workload they'll be doing. You want fast deletes on a
(Unless you're using the suspend patch a lot, you probably won't want journalling on the
A truly optimized system, therefore, isn't about picking your "one true love" of the filesystems. It's about deciding what criteria apply, and then looking to see what filesystem best meets that criteria.
A mixed-fs machine should be capable of out-performing ANY homogenous-fs machine, no matter what fs the homogenous-fs machine has picked, because a homogenous system will always be a compromise. A mixed-fs system need compromise nothing. (Other than your sanity. Which, being a geek, is just a hinderence anyway.)
I much prefer XFS; should be part of comparison (Score:2, Insightful)
XFS is by far the most durable, mature [given a long history inside IRIX] and featured of the Linux filesystems. I also am quite annoyed that RedHat doesn't make it easy to facilitate XFS right out of the box (rootfs support). They merged everything else in there, but somehow seem to favor ext3.
About the only thing I miss when using FreeBSD is XFS. While UFS2+S is robust and very quick, XFS is still my favorite.
I am also offended by RedHat that baits and switches a community by having popular (5.2/6.2/7.1-7.3) versions for free, then they start charging for this Advanced Server product on the same order of magnitude as Microsoft software [RH-AS is over $1000]. RH 8 and 9 are embarrassing. I obtained a copy of RH-AS, and the up2date feature doest work without a subscription, and the RPMS are not distributed in binaries. I'm glad there are several projects to replace up2date server for RedHat. All these problems on an OS that cant even be bothered to support XFS root filesystem.
FreeBSD is still Free. Thank goodness.
Re:Gee Re:Reliability (Score:5, Insightful)
On the contrary, that's exactly the case where you should always journal, and with full data journalling. You don't care about write performance, since you hardly ever do it, but you do care at lot about keeping your root filesystem consistent.
Re:Gee Re:Reliability (Score:3, Insightful)
Re:use Pavlovian Conditioning (Score:3, Insightful)
Windows 2000 and XP do this. No reason why Linux couldn't.
Re:use Pavlovian Conditioning (Score:2, Insightful)
> and hook the power button such that it runs proper shutdown..
You could, but that doesn't stop users from unplugging the AC power
cord and plugging it back in, which is what they'll do if the reset
switch doesn't work. You want things set up so that if they do that
once, they have no motivation to do it again next time (because it
didn't accomplish what they want, just like you said it wouldn't).
The problem is, common but unreliable operating systems have people
conditioned to solve problems by power cycling, because that's often
the only way and even more often will work. If you want them to not
do it, it has to not work.
Another way to accomplish this is to set things up so that fsck will
require significant (and, to a user, scary) user interaction if the
filesystem was not cleanly unmounted. That used to be the default,
but these days the default is probably journaling and no fsck at
all, or at least for fsck to run with no user interaction. For a
system end users don't have physical access to, that's good, but if
end users are present, it tends to give them the wrong idea (namely,
that unclean shutdowns are no problem).
This is an axiom every IT person should learn well: what's good for
a system end users touch directly and what's good for a system whose
users are powerusers or admins or developers are two different
things. A server can be in the latter category, but only if end
users can't walk up to it and use it directly. Lock it in a server
room and change the lock so that only the IT staff can get in (no
janitors, no non-IT managers, nobody but IT staff), or colocate it
in a datacenter, and you can treat it as an admin-type system.
Set it on a desk in the open office area where Joe Secretary can
touch it, and you have to treat it differently.
Though, I have a cgi server in an open office area... but I've
evaluated the risk. The power switches and stuff are toward a
wall (and it can't be slid out without being lifted, I'm the one
all my coworkers call to lift things), and it's headless, and it's
not the least bit mission-critical, and it backs up everything
that matters at all over the network daily on a cron job, and even
so I know what fire I'm playing with, having it where it is. I've
considered the possibilities, and the most worrisome one is the
power bar it's plugged into (under the credenza) getting bumped
inadvertently by someone reaching for a trashcan. I'm prepared
for the possibility that could happen at any time. The fact that
it's not the least bit mission-critical is significant to my
decision to leave it there, rather than trying to make space for
it in the closet with the T1 router.
Re:Reliability (Score:2, Insightful)
I didn't say one thing about ReiserFS. Not being an expert (and this being
On the record, the only opinion in my entire post was that it is easier to make something fast than it is to make something stable.
Perhaps I was too plain. This was not a judgement of ReiserFS. It was an opinion formulated by observation.