Slashdot Mirror
Reiser4 Benchmarks
unmadindu 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."
hey, I can live with an unstable gnome or Kicq, but a beta filesystem?? no thanks dude!
After reiser4, what filesystems are actually decent competition for it? It'd be nice for OSS to claim not only the best web server (apache), best kernel, and best filesystem.
Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
The statistics on that page are measured in seconds, no? So larger numbers are worse.
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).
May we never see th
While great, this announcement/benchmark/statement does not mean that ReiserFS V4 is ready for production use, just that it is fast. It needs a lot more bug testing before then, so don't rush out and mass-convert to V4 just yet! See here for the full thread, rather than just the first post...
* Several monkeys are here, playing banjos and wearing small hats.
Exactly. RAM, CPU, and storage space are ever increasing. Now we need better ways to organize data, access it, protect it, and back it up.
The fact of the matter is, it is easier to make a fast system than a stable, reliable one.
It's still not time to swap it for ext3 for general use.
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
That would be interesting.
> > they would just hit the reset button
>
> 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.
Cut that out, or I will ship you to Norilsk in a box.
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.
Operations are journalled in such a way that instead of updating the directory entries (or the file allocation table, or whatever applies to that specific FS) and then writing the new file contents, ReiserFS writes the new contents, and _then_ updates the directory information.
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.)
Somebody get that guy an ambulance!
Root is a prime candidate for a small (100MB should do it) ext2 system mounted "sync". You don't need decent write performance on root; in fact, many sysadmins make it read-only. Journalling is pointless if you're only writing to the filesystem once every 6 months to add a new user.
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.
Have you got your LWN subscription yet?
It's nice to have your log files mostly intact after a hard reboot, too.