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."
My one concern is reliability and recovery from failure; I've had a few cases where my belief in ReiserFS has been questioned; however I can't get Ext3 to build on larger than 500GB arrays.
At this point I'd happily choose based on reliability/recoverability/stability not raw speed.
With all of the focus on the latest hardware and graphics, it's good to know that improvements are being made across the board like this. It gives me faith that Moore's law is a long way from failing!
stuff |
Does anyone know if there will be a conversion utility available - i.e, to convert ReiserFS v3 partitions to v4?
This space intentionally left blank.
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.
I am curious as to whether there are any projects to port Reiser4 to *BSD, particularly FreeBSD 5.x. Does anyone have any thoughts on how difficult a port might be? Can somone more versed in filesystems on *nix enlighten me as to the implimentation differences?
**AA: a bunch of mindless jerks who'll be the first against the wall when the revolution comes
...is mostly funny, but is too much of a company filesystem to trust completely.
In case anybody cares, "strelka" means "arrow", and "belca" means "squirrel"
Wonder what naming system they're using. I use names from Alice in Wonderland.
All these numbers are nice, but I can't make heads or tails of them. Since these are times, I assume lower numbers are better? If so, they why are they usually in red in the report?
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?
-"One machine can do the work of fifty ordinary men. No machine can do the work of one extraordinary man." -EH
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.
You'll probably have to compile it in yourself for now.
RH probably will include it in the future, but probably won't give you the option to install on it without jumping thru major hoops.
RH seems to suffer from a big case of "not-invented-here-itis", and RH users sometimes suffer for it. Not having ReiserFS is one way in which they do.
I realise that it is a bit early to adopt V4, but stable issues aside, which filesystem would YOU choose to for database volumes for fx. Oracle or MySQL?
my sig
Like "Three Dogs Playing Poker" to the Mona Lisa.
How does it compare against everyone's favorite, XFS?
Prescriptive grammar:linguistics
So he's submitting it to 2.6, but what are the chances it'll get submitted? Isn't this what caused all of Reiser's bitching a couple of years ago? He waited to long to get RFS into the kernel and ran into the feature freeze, and then pitched a hissy fit.
.
I'm not sure about the exact reasons why they don't support various other filesystems. The default bootup sequence of a RH system uses an initial ramdisk, and actually scans each partition available to find out where they should be mounted (they created nash, NAno SHell, which is just simple support for shell commands as well as fs label scanning). That's why you see the LABEL=/ in your /etc/fstab on a RH system. ResiserFS didn't support filesystem labels until 3.6, so using this setup could mess things up (with 3.5 or older), and justifies your point about having to "jump through hoops" to get reiserfs working. The simplest way I found to move to reiserfs was to change all the LABEL=??? specifications to actual device files, boot from a recovery disk, move everything around while reformatting the partitions as another filesystem, then finally rebooting.
Anybody know what, if any, features are being added for the laptop user? Last time a checked, journaled filesystems, like ext3, were generally a no-no if you wanted you battery to last.
Maybe a filesystem just for laptop/tablet pc users?
DELETE (time in secs to perform action)
:(
40.13(R4) 0.797 (ext3 journal) 0.837 (ext3)
woo-hoo! now it corrupts my data even quicker
http://milkshake.dexy.org
I know a lot of people will pull their hair out when they hear this, but: Speed is my primary concern. On long compiles of new programs or kernels for example the speed difference on a good FS can be important. I'm not saying that I'm willing to have a FS that corrupts every last file and directory, only that given two FSs which both have seemingly similar stability I would prefer the speed boost.
I have tried one or two of the FSs but I haven't used them for any length of time to be able to compare one against another.
In this note, Hans Reiser clearly states his position: you trade off filesystem metadata performance against data integrity.
Once you realize that this maintains your filesystem structure but turns your files into Swiss cheese (this happened to me several times) you'll switch to ext3 or XFS.
Since reiserfs continuously rebalances the block tree, files that are only open for reading can be trashed by having a block exchanged with the last file written before a crash.
Hans is recklessly pursuing optimization of one aspect of filesystem performance. I honestly believe DARPA should reconsider funding his current track of work.
I attended Hans' presentation at Linuxtag.
Basically, reiser4 is optimized for the case where you unpack a large tarball, say the Linux kernel, and have enough memory to hold it all in cache, which is true for most of us these days. reiser4 will then choose the optimal disk layout for these files and flush them to disk.
Hans also has aspects of a log structured file system in reiser4, which means you don't write to the file, you write to a log file which basically encompasses the whole disk. The up side is that you mostly write linearly, the down side is that the files get badly fragmented if they are updated at all. Most files are not updated, just written once at installation of the package. The files that are updated frequently tend to be source code from CVS, which are small enough to fit in memory completely and have reiser4 choose an optimal disk layout again.
The case where this model completely sucks is the case where you update many portions of a large file. For example, running an SQL database with files on a reiser4 file system as backend, or maybe a DNS server with DDNS, or a berkeley db backend for Postfix or qmail to keep the SMTP AUTH users or something. Also, log files will probably be badly fragmented.
Hans proposes to have something like a transparent defragmenter running in the background, which he calls "repacker". This would run in the kernel space, as part of the file system, and defragment badly fragmented files that are accessed frequently. This would solve most of the down sides of his approach, but this repacker is not finished yet.
My personal view of reiser4 is: it looks like it is optimized to perform well in benchmarks. It tries to be fastest for updating databases, but buys the performance by being slower when reading the data afterwards. The critical question is whether the repacker can alleviate these concerns, and as long as it is not finished, reiser4 is basically out of the question except for a little testing here and there. I reckon reiser4 would be a great filesystem for keeping your mozilla and gcc CVS checkout handy. But until the repacker is done, I will not even use it for testing, because the repacker really is the crucial component that makes or breaks this.
By the way: my previous experiences with reiserfs were less than stellar. Some people call it shredderfs instead. The main complaint with reiserfs is and always was that the fsck is not nearly as trustworthy or stable as the one from ext2/ext3. So even if I use reiserfs at all, it's only for data I can afford to lose completely, like my CVS checkouts or the squid cache directories or something like that.
The benchmarks do look good though, and I am glad that at least someone is still trying major innovations in this area. Since most Unix vendors or divisions are no longer profit centers, file system innovations have largely stalled or moved to specialized companies who regard them as proprietary (Veritas) instead of releasing them as free software like IBM and SGI did.
I know ext2 isn't a journal fs, but it would still be interesting to see a direct comparison again reiser4.
Marge, get me your address book, 4 beers, and my conversation hat.
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.
that may be true for existing systems, but in the case of running an install from cd, instead of taking the default, add either "reiserfs" or "reiser" (don't remember which - think the "fs" one) to the boot options at the prompt when booting from the cd. it then adds reiserfs to the list of filesysems you can choose to format new filesystems with in the partitioning tool. pre-existing reiser filesystems will be handled correctly if you don't format them.
rh supports reiser just fine - they simply hide the option, probably because they feel ext3 is a safer choice.
..but however remember that both have different strong points:
XFS is especially good in dealing with large(and when I say large I mean *LARGE*) files, and IIRC, the all idea behind the Reiser filesystem is to deal with small data objects.
Anyway, it'd be interesting to see such a benchmark as XFS has the reputation of one of the best(the best???) fs to be used with high hard-disk I/O-s and even higher system loads.....
1. No sig. 2. ???? 3. Profit!!!
Apple benchmarked their new G6 processor against the latest 10 GHz Pentium V. They say that despite its lower clock speed, it runs their suite of PhotoShop 8 filters almost four time faster than the Pentium.
Seriously, Hans Reiser is benchmarking his own file system, and he's using benchmarks that make his system look good. Like the SpriteLFS, his filesystem has a log structure for sequential writing, which makes it look really good in tests like he performed where you write the files once.
Compare a database load, where you write small chunks of big files all the time. Without the repacker (like the cleaner in LFS), the disk becomes horribly fragmented. With the repacker, you have to include the slowdown of this background process defragging your hard disk. Ick.
I'll trust his benchmarks when he presents a final, stable release, with the repacker on, and tests it under workloads such as would be encountered on a server. I might use it on my homebox even if it sucks on a server, but it would be nice to know that he considers his structure's impact on other workloads.
I hereby place the above post in the public domain.
Didn't linus say no more new features at this point? Didn't Reiser try this same damn thing last time, fighting with the kernel people to get his stuff in after the feature freeze?
Need Free Juniper/NetScreen Support? JuniperForum
I'm not putting thousands of files in a single directory. I'm not using tons of small files, and my hard drives are more than big enough to hold my data. Is there any reason to use reiserfs instead of ext3?
> > 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.
The first thing that popped into my head when I read that was "uh... feature freeze two weeks ago." I'm sure Reiser's going to have another of his babyish hissy fits. I see another slashdot story in the near future.
<Reiser> Oh, what about my sponsors! Why are you all playa hat'n on me?
<EveryoneNotOnTheReiserCheerleadingSquad> You don't get special treatment. You waited too long, and we're not putting your untested code into a frozen code base.
<Reiser> You're oppressing me! The GPLv3 will fix you all!
<SomeoneFromFSF> Please shut up, Reiser. You still don't know what the fuck you're talking about.
<Reiser> Wahh!! My sponsors!
<Everyone> SHUT UP REISER.
I'm as mimsy as the next borogove but your mome raths are completely outgrabe.
What about upgradablity? The nice thing about ext3 is that upgrading to a new
version is a reboot away. With ReiserFS, you had to re-format the drive, in
order to upgrade. Has this changed?
SealBeater
-- Its survival of the fittest...and we got the fucking guns!!!
Yep. 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.
Dewey, what part of this looks like authorities should be involved?
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.
The simplest way I found to move to reiserfs was to change all the LABEL=??? specifications to actual device files, boot from a recovery disk, move everything around while reformatting the partitions as another filesystem, then finally rebooting.
Really? The simplest way I found to move to reiserfs was to use Suse.
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?
I have some questions abou ReiserFS and was wondering whether someone out there would be able to answer them.
.../customers/0001/name .../customers/0001/phone .../customers/0001/agent -> .../personnel/0021
First off, there's this stuff with ReiserFS storing fine-grained data. Does this imply that using ReiserFS (v3 or v4) directly as a database would be efficient? I know RFS doesn't have Relational features, but these might very easily be implemented in userspace if you can store e.g.:
(...etc.)
Am I losing this or getting this???
My other question was about this metadata-as-file thing. Hans can implement whatever he wants, but it just so appears that Linux behaves like Unix. I've just made a ReiserFS partition to check, and there's no way I can "touch foo; ls foo/" to see e.g. permissions etc.
Now I'm aware that this might be v4 stuff, but I wonder if anything of this is ever to be seen back in Linux userland? E.g., will it be possible for projects to use ReiserFS to change the paradigm used for metadata using a straight Linux kernel?
See, from time to time I just happen to be quite impressed with the "everything is a file" applied to metadata, and I hope we can make the shift to this future one day, and finally get rid of file extensions, MIME guesses and app association registries in Linux, and store this stuff in metadata space.
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
Having used and tested about every file system, I have been using XFS exclusively even for my customers. Ext2 is solid but not good for production machines which need to be able to reboot without a manual fsck (this is why we started discussing journaling file systems in 1997 after all). ReiserFS managed to shred some of my files on root filesystems. Ever had a file which you could not delete without the rm command going haywire? Since then, I've been using XFS even on the largest RAIDs without any problem.
But let's wait and see how fast and stable reiser4 is once it matures into the stock kernel.
open (SIG, "</dev/zero"); $sig = <SIG>; close SIG;
The drivers are crap, and the box dies about every week or so
You should call the server "Kenny"!
As in Southpark: Oh my God you killed Kenny!
From excellent karma to terible karma with a single +5 funny post...
It's nice to have your log files mostly intact after a hard reboot, too.
The core XFS might have been mature in IRIX but it most definitely is not in Linux.
XFS is still not a fully linux-native fs, it is IRIX code pasted into Linux through a special translation layer. And thats where most of the problems arise, as it has to translate IRIX-isms to Linux-isms.
No Red Hat isn't afraid of kernel upgrades.
Red Hat is providing an ABI guarantee that Linux normally doesn't provide though.
Specifically, other vendors (Oracle, Veritas, IBM, etc) have kernel modules compiled specifically for the Red Hat enterprise 2.4.9 kernel.
Red Hat has committed to keeping the source and binary interfaces stable and compatible for the duration of the 5 year life cycle of Red Hat Linux.
Updating the kernel would break all of that.
BTW, yesterday Red Hat released a beta of the RHEL 3.0
For the most part, ext3 should work fine for individual users. If your were doing a lot of sound or video, you might see a performance improvement with reiserfs. The big issue with jounalling is fast reboots after unclean shutdowns. This might happen a lot at home if you have small children (future sysadmins!). ext3 and reiserfs-v3 only journal the meta-data, ie, the structure of the FS, not the actual file data itself. But that is huge, since it essentially prevents an unrecoverable disk, and eliminates the need to completely walk the structure tree when mounting an unclean disk (fsck), very time consuming. But you can lose data on open files.
User: Um, I rebooted the box. Er, was that, like, okay?
You: Und so... Ve haff earned ourzelfs ein timeout in "The Box", hein?
User: Aiiieieieieeeie!
You: Mua-ha-ha!
[Fade to black]
I like the UFS2 FS for FreeBSD. Its stable but a little sluggish. I think it would be cool to have internal competition but the MS GPL == viral crap has made a dent into the BSD developers. They fear linking to anything gpl would make their kernel gpl as well.
Anyway this is just a pretty please with a cherry on top. Especially since you are being paid for by grants from DARPA who use Solaris, Linux, FreeBSD, and every Unix os under the sun.
http://saveie6.com/
>> ...we also have some 3Ware cards we could try if the new Promise drivers don't do the trick. ;).
>>
>
> What are you waiting for! You'll be trying the 3ware cards in a couple weeks almost guaranteed
Is that a promise?
include $sig;
1;
ReiserFS is really good at some things (and I actually recommend it for some things) but for my main system filesystems, I find that Reiserfs lacks some of the things that EXT2/3 has that are very useful--
File attributes including things like "Append Only" although these can also be ways of screwing up your system (who'da thunk Qmail doesn't like append-only log files?).... See man chattr for more info....
So I am happy to use it for directories where I don't have special needs for the filesystem, but for others, I have to still use ext3.
LedgerSMB: Open source Accounting/ERP
Yeah, who is the guy anyway. Oh wait, he's a kernel developer who has worked on journaling file systems (Tux2,ext3). Your parent was not bogus, he was right. Just because you flush things to disk aggressively doesn't mean they are always consistent. There are still short times where things would mess up if the machine lost power. With full journaling the file system is *never* inconsistant. The only thing you'd want sync for is the push the latest cache versions out to disk; but it would be best to do that on a journaling FS.
This would be a much mre useful posting if you specified what command was behind that `time` output.
I've been doing similar testing and have seen significant differences in numbers based on the io load / pattern. Each FS has its own strengths + weaknesses.
Was it: random or sequential? big files or small files? consecutive io or single reader/writer?
This stuff makes a BIG difference in the relvance of those numbers. Yuo probably know that if yu're doing testing, but it'w worth psting for those wh may not.