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."
Reliability (Score:5, Interesting)
At this point I'd happily choose based on reliability/recoverability/stability not raw speed.
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:Reliability (Score:5, Informative)
ReiserFS does have speed as a goal; however, with ReiserFS 4, all filesystem operations are now atomic, which is functionally equivalent to having full data (not just metadata) journalling.
In addition, having the fastest CPU in the world won't make ext[23] better at things for which ReiserFS is fast.
CPU speeds are increasing. Storage space is increasing. RAM is cheap.
However, none of that equates to "disks are fast". Having a fast CPU with a slow filesystem is like having a gigabit LAN connected to the Internet via dialup. Sure, internally you're quite good, but throughput will still suck eggs.
The fact of the matter is, it is easier to have no clue what you're talking about than to read a little bit before posting.
Features (Score:3, Interesting)
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
Re:Features (Score:4, Informative)
Are there features other than attributes provided by ext[23] which ReiserFS can't provide?
Regarding the attributes, ReiserFS can't do the following "useful" things:
- Excluding a single file from access-time logging.
- Append-only would be useful in certain cases.
- 'c' (compress file contents) -- Ext[23] doesn't do this yet, and ReiserFS doesn't either, but they both will support it later.
- 'D' (dirsync) attribute -- Other than ensuring that filesystem metadata operations are completed successfully before proceeding, I can't imagine a beneficial use of this attribute. ReiserFS already journals all metadata, and V4 journals everything (and does it faster).
- 'd' (do not back up using dump) -- AFAIK you can't use dump to back up a ReiserFS partition anyways, but tar still exists, and I'm sure there are wrapper scripts for the die-hard dump users.
- 'E' (error in compression) doesn't seem to apply to general (current) use of ext[23], and doesn't have an analogue in ReiserFS.
- 'I' (hash-indexed directory) -- ReiserFS' directory algorithms are much (much!) faster than ext[23]. ReiserFS will eventually support directory plugins, which allow one to set a per-directory hashing scheme. I note that ext[23] doesn't allow modification of this attribute, so I'm not sure if/how it allows you to choose a hashing scheme.
- Immutable ('i') bit -- This might be useful in some circumstances, such as a setuid binary. Not supported by ReiserFS.
- The 'j' option is meant to get around the fact that ext[23] only journals metadata unless mounted with "data=journal". As mentioned elsewhere, ReiserFS' long-term goal is to provide fully atomic file operations, which provides the benefits of data journalling with none of the burdens. Thus, ReiserFS V3 doesn't support this attribute, as the time spent in adding this feature would have been better spent working on V4. Note that with V4 all operations are atomic, which has the effect of turning this flag on for every file.
- 's' (zero file contents upon delete) -- ReiserFS doesn't support this.
- 'S' (write file synchronously) is likely used in cases where preserving file integrity is important. ReiserFS' journalling (especially in V4) provides this "for free".
- 'T' (top of directory heirarchy) is used to get around an ext[23] weakness. I don't recall details, but I believe it's something related to preventing fragmentation and grouping similar files together for enhanced performance. ReiserFS (especially V4) is already quite fast, and with code-level optimizations will likely get faster.
- 't' (don't merge tails) does not apply to current ext3 code, as tails aren't yet merged anyways. This will be used as a flag to write the file to disk in such a way as to be compatible with LILO and other boot loaders. At present I'm not aware of any special issues with ReiserFS' tail packing (which does exist, by the way) with respect to LILO. Note that a ReiserFS partition can be mounted with the "notail" option if you want, which is feature-wise equal to ext[23], which don't seem to provide tail packing at all right now (and if they do, someone needs to update the chattr man page).
- 'u' (back up upon deletion) -- ReiserFS doesn't support this.
- 'X' and 'Z' relate to compression, and do not apply to ext[23] or ReiserFS at the moment. ReiserFS will eventually support compression plugins, as well as encryption plugins.
So of the attributes, the only ones which might actually be of some use in the context of ReiserFS would be exclusion from atime logging, append-only, the immutable bit, zero-contents-upon-delete (although future crypto plugins will destroy the need for this feature), and back up upon deletion.
Anything I've missed?
Re:Reliability (Score:5, Informative)
The drivers are crap, and the box dies about every week or so. Haven't lost a single file yet, and we're at 91% filesystem useage (millions of files).
The / filesystem is ext3. It's about 20gigs, and has had to have files restored several times.
I have a lot of confidence in ReiserFS, after seeing the incredible amount of abuse on this one particular machine. I have run ReiserFS for quite a while now (ever since it was part of the kernel) for all of my home systems, and have never had a single issue with those filesystems.
Looking forward to what ReiserFS4 will bring.
Re:Reliability (Score:5, Interesting)
Had me confused to hell until I saw a newsgroup discussion that mentioned the exact problem I was having. Does Hans Reiser know about this problem? Oh, yeah. He does. Is he concerned about it? No, he's not. In his own words he's not. And ReiserFS fails silently; you'll never know until you find it.
When I setup ReiserFS on my machine, I was aware of similar complaints, but I dismissed them as fear of trying something unproven. And I was happy with ReiserFS for quite awhile, because I never saw anything wrong (unlike ext2/3). But I really can't support a FS that has these kinds of data integrity issues if the team has that kind of attitude towards them.
Re:Reliability (Score:5, Informative)
Be warned though, that all fixed location journals double the transfer time cost of performing writes because the data must first be written to the journal, and then written somewhere else. This is why we don't make data journaling the default in v3. Trust me, full data journaling would have been far easier to code first than meta data journaling, but it isn't in the interest of the 'average' user.
Now V4 is an atomic filesystem, which is much better than data journaling, because it means that all filesystem operations are performed fully atomically. Your write syscall either fully happens or it does not. Applications can have multiple filesystem operations performed atomically. We do this without writing the data twice through use of a technique called wandering logs, which I describe in a posting below (and on our website).
Apologies, couldn't resist (Score:3, Funny)
>>
>
> What are you waiting for! You'll be trying the 3ware cards in a couple weeks almost guaranteed
Is that a promise?
In that case... (Score:3, Funny)
You should call the server "Kenny"!
As in Southpark: Oh my God you killed Kenny!
Re:Reliability (Score:3, Informative)
First I don't get what you mean by "huge amount of stuff in the partition"... In no place does he actually say that _anything_ is being stored on the root partition (we can assume it's an OS only partition).
It's probably a server with an internal 20GB drive connected to the 1TB raid. If you're suggesting the 20GB is a partition off the raid, well then you have no clue how these things work.
Re:Reliability (Score:3, Funny)
Wow, that's a neat technique. He said nothing even remotely like your first sentence, but you claimed that's what he said so you could easily "destroy" his argument. Let me try:
If you're saying that Queen Elizabeth and her band of merry men is responsible for the block size on his RAID array then you have no clue how
Re:Gee Re:Reliability (Score:3, Informative)
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:Reliability (Score:5, Interesting)
We're just a small grant lab at a university, so it's not like this was a corporate system or anything, and there had been hardware problems before. Given that most of the people are not techies, they did not know how to ssh in and shutdown -r now, so they would just hit the reset button whenever they thought something was wrong and I wasn't around.
Anyway, because of Reiser's journalling, the system would come right back up after a forced reboot. I think that the guys in the lab cut the power a couple of times to many and the hard drive just gave out.
By the way, I just had a tech install a new drive, and Debian base with ssh. I knew the password he would use for root, and I was able to rebuild the entire system and restored 250,000 records in half a day.... From North Africa.
Try that with a non-*nix.
Re:Reliability (Score:5, Funny)
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...
Re:Reliability (Score:4, Funny)
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
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:use Pavlovian Conditioning (Score:3, Insightful)
Windows 2000 and XP do this. No reason why Linux couldn't.
F**k Pavlov, use Skinnerian Conditioning (Score:3, Funny)
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]
Re:Reliability (Score:3, Funny)
Re:Reliability (Score:4, Funny)
Re:Reliability (Score:3, Funny)
Try that with a non-*nix.
Aw, that's a non-issue. MCSEs are so cheap that it's no problem to always keep at least one MCSE within a 200 meter radius (300 meters if the MCSE is not overweight and under 30) from the system for 99.9% uptime.
Re:Reliability (Score:3, Interesting)
Re:Reliability (Score:4, Informative)
RAID5 would give you a 1.75TB partition with the equivalent space of one drive reserved for fault tolerance. My preference would be RAID5+Spare with that much space which would give you a 1.5TB partition with 250GB reserved for fault tolerance and one hot spare drive in case one of the others fails. With that setup, you're okay until you lose three drives.
Jason
It's really good that filesystems are maturing too (Score:2, Insightful)
Re:It's really good that filesystems are maturing (Score:2)
I can see where your stated "faith that Moore's law is a long way from failing" is "kind of" in keeping with Moore's law...
Conversion? (Score:5, Interesting)
Re:Conversion? (Score:3, Informative)
Re:Conversion? (Score:2, Informative)
Re:Conversion? (Score:5, Informative)
However, there is a tool called convertfs (as well as tar) which can convert V3 to V4. It can also convert ext2 to V3 or V4 or V3 or V4 to ext2. It is pretty clever (and written by someone outside our team), in that it creates a loop back mounted target filesystem inside a file inside the source filesystem, copies everything from the source to the target, and then reshuffles the blocks of the file so that they are at the offsets on the device that they were at within the file.
Re:Conversion? (Score:5, Funny)
Re:Conversion? (Score:4, Interesting)
(see page 9 of this PDF for the graph) [linuxsymposium.org]
The implication is a lack of fine-grain locking. Does this new all-atomic, all-the-time implementation automagically bring better locking too?
Re:Conversion? (Score:3, Informative)
Re:Patch for FreeBSD request?? (Score:4, Interesting)
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.
ok (Score:2)
Re:ok (Score:4, Interesting)
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.
Re:ok (Score:5, Informative)
Re:ok (Score:3, Informative)
rh supports reiser just fine - they simply hide the o
Re:ok (Score:3, Funny)
Really? The simplest way I found to move to reiserfs was to use Suse.
wait! (Score:5, Insightful)
hey, I can live with an unstable gnome or Kicq, but a beta filesystem?? no thanks dude!
Re:wait! (Score:3)
As it goes for me I can do that with no pain. Seeing what r4 provides migrating my things to r4 would be good. But first place for beta fs is spare machine that is just used to crash test this filesystem.
Re:wait! (Score:3, Informative)
Yep. Testing a beta filesystem is something you do on a spare machine that you are not using at the moment. It would be really cool to help test ReiserFS out, but I only have one machine and can't risk losing all of my work!
Reiser4? Competition? (Score:5, Insightful)
Re:Reiser4? Competition? (Score:5, Funny)
--
Sick of gentoo zealots throwing plugs in completely unrelated topics? Me too!
Not to mention the best software installation system ( portage ).
Re:Reiser4? Competition? (Score:3)
Re:Reiser4? Competition? (Score:3, Informative)
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 feat
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.)
Re:Reiser4? Competition? (Score:3, Informative)
I think they are using the Plan 9 network filesystem protocol (9P2000), not the Plan 9 local filesystem (which isn't anything special AFAIK).
Honest Portability Question (Score:5, Interesting)
Re:Honest Portability Question (Score:2)
The Paul Reiser filesystem... (Score:2, Funny)
Computer's names translation (Score:5, Informative)
Wonder what naming system they're using. I use names from Alice in Wonderland.
Re:Computer's names translation (Score:5, Informative)
Quote from first google search result: "Belka("Squirrel")and Strelka("Little Arrow") were launched into space on board Sputnik 5 on August 19, 1960. They were accompanied on their historic flight by 40 mice, 2 rats and a number of plants. Belka and Strelka were safely recovered after spending a day in orbit. Strelka eventually gave birth to a litter of 6 healthy puppies, one of which was given to President Kennedy as a gift."
Re:Computer's names translation (Score:3, Funny)
Re:Computer's names translation (Score:2)
Re:Computer's names translation (Score:5, Interesting)
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?
Re:So how much better is this really? (Score:3, Informative)
The columns marked B/A and C/A are the performance ratios of ext3 data journaling and ext3 to reiserV4 respectively. A ratio greater than 1 means more time was needed for the operation than reiserV4 while a ratio less than 1 means faster performance.
Re:So how much better is this really? (Score:2)
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).
Re:I don't understand the statistics (Score:4, Informative)
B. ext3 data journalling
C. ext3
That's how the filesystems are lettered. In the column headers, you see this:
A B/A C/A
So it looks like the first column is the actual time for reiser4 (A), the second column is the ratio between ext3-j (B) and reiser4 (A) which is B divided by A, and the third is ext3 divided by reiser4. So if the number is > 1 (red), it means reiser4 took less time and might be "better". If the number is 0 (green) it means reiser took MORE time.
I think.
Re:I don't understand the statistics (Score:2)
Or am I missing something?
Re:I don't understand the statistics (Score:5, Informative)
I would have fixed this before posting to lkml, but I had to catch a plane, sorry about that.
Bugs (Score:4, Insightful)
Which to choose for DBs? (Score:5, Interesting)
Re:Which to choose for DBs? (Score:3, Interesting)
Re:Which to choose for DBs? (Score:5, Informative)
Re:Which to choose for DBs? (Score:3, Informative)
1. If you're using a filesystem for databases, then the chances are you're keeping other stuff besides the database on them. Otherwise, you'd use a raw partition.
2. I believe that by default data changes to files aren't journalled in either of the systems that were being compared; only filesystem metadata changes. This doesn't cost much in terms of resources, particularly if the metadata rarely changes (as I suspect it doesn
XFS? (Score:5, Interesting)
Re:It may be interesting to know... (Score:2, Informative)
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.....
Re:XFS? (Score:3, Insightful)
I'd also like to see it compared to JFS and maybe ext2 (if not ju
but will it make it (Score:5, Interesting)
Me too™ (Score:4, Funny)
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.
Re:but will it make it (Score:4, Interesting)
The point is that unless reiser4 is 100% self contained and stable it shouldn't make it into 2.6 at all now because there's been a feature freeze and a new filesystem and anything else it adds to the kernel are features. Hans waited too long, again, and technically reiser4 shouldn't be included in the standard/Linus kernel until 2.7 now.
XFS wasn't allowed to be included in 2.4 officially because of those reasons but the SGI developers didn't cry about it, they just kept their patches up to date and waited for 2.5 to start so they could get included.
If the filesystem is actually stable and has real benefits over ext3, XFS, JFS, etc it'll probably be patched into distros like RedHat anyway so it's not a huge deal.
Filesystems for the laptop user? (Score:4, Interesting)
Maybe a filesystem just for laptop/tablet pc users?
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.)
unfair - but true for me at least in the past (Score:4, Funny)
40.13(R4) 0.797 (ext3 journal) 0.837 (ext3)
woo-hoo! now it corrupts my data even quicker
Which is best? (Score:3, Interesting)
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'm going to disagree with you (Score:2)
of course if you've got a cluster of 100 machines that are all doing the same things and you can even make the app go 5% faster by a different filesystem, that can be a saving of $20,000 or so.
"but you won't need to fsck" (Score:2, Informative)
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
Re:"but you won't need to fsck" (Score:2)
That note just says what is common knowledge already, that if you want an actual crash proof system you need data journalling. I know very, very few people who use this, because it effectively means writing everything twice, which kills performance. That doesn't reflect upon ReiserFS at all, many filing systems don't support data journallin
Re:"but you won't need to fsck" (Score:5, Informative)
That was V3. V4 is an atomic filesystem, which means that every filesystem operation is performed as a fully atomic transaction. This is more secure than the guarantees of data journaling, as data journaling doesn't necessarily guarantee that the write will complete.
The reason we are able to do this in V4 but not in V3 is that V4 uses what I call wandering logs. With wandering logs, instead of copying data first to the journal, and then after commit copying it from the journal to the rest of the filesystem, (thereby writing the data twice), we just change our definition of where the journal is. I don't think that data journaling is worth going half-speed for most users. With V4, we not only don't go half-speed, we go faster than V3 ever went.
For more details, please take a look at http:www.namesys.com/v4/v4.html [namesys.com]
About reiser4 (Score:5, Informative)
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.
Re:About reiser4 (Score:5, Informative)
The difference between us and an LSF is that we perform well BEFORE you run the repacker, and we merely perform even better after you run it. LSF's required that you run the repacker to get good read performance, we don't. V4 kicks V3's butt without the repacker by a lot (due to dancing trees, allocate on flush, extents, and ending the use of BLOBS, among other things). With the repacker, it will just kick it harder.
Our approach synthesizes a lot of approaches, rather than considering one technique to be the answer to everything. This makes our performance more robust, as the different approaches each cover over each other's lackings. There are some situations in which using a repacker is higher performance than making lots of little changes while constantly maintaining optimal allocation of files.
The repacker will be ready in a few weeks.
ext2? (Score:3, Interesting)
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.
In other news... (Score:4, Interesting)
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.
Comment removed (Score:3, Interesting)
Should I bother? (Score:3, Interesting)
Upgrading... (Score:3, Interesting)
version is a reboot away. With ReiserFS, you had to re-format the drive, in
order to upgrade. Has this changed?
SealBeater
some questions abou ReiserFS (Score:3, Interesting)
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.
Re:some questions abou ReiserFS (Score:5, Interesting)
If you want to be able to "cat filenameX/..owner" to see who owns "filenameX", you need to use V4.
Re:Comparison (Score:3, Funny)
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.
XFS is not mature... not in linux anyway (Score:3, Informative)
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.