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.
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.
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
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
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.
.
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?
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.
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.
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?
These are the names of the two dogs that were sent into outerspace by Russia.
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!!!
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]
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/
For my usage patterns/needs and in my experience; I have found it far more difficult to produce catastrophic failure in XFS.
Anything referred to as Irix-isms is Irix has a proper implementation, and Linux needs to do catch up.
As far as problems go, I have seen from time to time a few errata/bugs associated with release code, but I also see quite a bit of bizarre errata/bugs for Reiser and EXT3. Some of which are not corner cases but foolish oversights.
I have to say being multidextrous with various *nix, and being agnostic towards OSes - my encounters with FreeBSD shows that filesystems don't have to be a kludged mess.
I'm looking forward to 2.6 for a number or reasons (and hope to see a lot of thrashing eliminated that has become linux's trademark on even bigmem systems), but for XFS being bolted in as part of the kernel.
Read the EXT3 mailing lists or check out a few newsgroups. Its not without problems. And as far as Reiser goes, it may be faster in some cases, but I dont take R3 very seriously, especially after all the whining hans has done towards the linux kernel and towards compilers. Sure, Linux has flaws and RedHat's compilers produced suspect code, but filesystem code isnt a place to be messing around with code that is easily mangled.
XFS and somewhat JFS are in my estimation the only serious filesystems for Linux.
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
An argument has been going on at one of the distro mailing lists. It basically boils down to this:
ReiserFS, currently, requires a reboot after the filesystem is installed, but prior to completion of the installation of the distro, does it not?
I know that this was a requirement earlier. Whether this was "fixed", or the reboot requirement was removed in a subsequent update, I do not know. But I do remember reading this at the Reiser site, and elsewhere. I also remember reading that the reboot requirement would be removed with Reiser4. Whether this reboot requirement has been removed somewhere in the 3. series, I do not know.
The distro authors have justified their non-reboot installation by saying that it is not required under Suse either. I remember reading elsewhere, though I can't remember where, that Suse had developed specific patches to Reiser 3. series to eliminate the reboot requirement, and a comment was made as to a hat tipping or something similar, to the coding abilities of Suse.
Since I can't find the above information, and can't remember where I read it, the concerns have been dismissed. But the reboot issue has cropped up again on the list.
Other than Suse, does the current, ReiserFS, the versions prior to Reiser4, require a reboot? If not, starting at which dot release has the reboot requirement been removed?
And thanks for a great filesystem! I use it for everything.
As a side note, one or several distros require to dump everything into