Slashdot Mirror
Rewritten ReiserFS 4 Promises 2-5x Speed Increase
An anonymous reader reports that version 4 of "ReiserFS will be released in first quarter. Complete rewrite will support Atomic writing. 2-5 times faster. File corruption will be a thing of the past. Lindows.com is paying for part of it."
I'm now using ReiserFS 3 on most of my home systems and I must say it works quite well. Haven't had any problems so far with any of them so a version that's 50% faster sounds very good to be.
Too bad not all distros offer it during the installation.
IP Therefore I am.
I cant say I would ever run Lindows, but it definately raises my impression of them that they are continuing to support reiserfs.
This is an example of how a corporation can benifit from OSS and share that benifit by contributing back to OSS developers.
The Ro Factor - Jeep/Linux Weblog
Or if that is too much to digest, I wrote a fairly easy to follow summary on kuro5hin.
- I don't need to go outside, my CRT tan'll do me just fine.
I'm glad to see this. I remember when Lindows was announced, the general reaction here was, "Why create something to emulate Windows?" and there was a level of contempt here because it was so easy to use (as there always is here -- almost like a reaction of people insecure with their own status).
They're also sponsoring a project involving KDE (forgot exactly what) and NVu (a full WYSIWYG HTML/Site editor based on Mozilla for Linux). Lindows is an excellent example of good citizenship in the FLOSS world. It's true they are a pay-for-only distro, but they are definitely giving back to the community -- in ways the community needs and other people/companies are not supporting.
Yes-- this is far too late to save ReiserFS on my installation. I moved all our disks to ext3 a few months ago after experiencing extensive file corruption. A scsi disk went bad. When it went down, all files that had been active at the time were corrupted. Mostly that was several dozen mail spool files. Didn't I switch to a journaled file system in part to avoid this sort of thing? Grrrrrrrrrr.
...so much so that I'm going to call my daughter Reiser. Sounds nice don't you think?
-----
One is born into aristocracy, but mediocrity can only be achieved through hard work.
Does anyone have a good compare and contrast of ReiserFS 4 and WinFS? Looks like there are some similarites in functionality.
The same guy who is running Lindows.com used to run MP3.com -- which also contributed to ReiserFS. It's interesting to see how Robertson is personally involved in the technical running of his businesses.
He who laughs last is stuck in a time dilation bubble.
Both ext3 and reiser3 offer(ed) data journaling, which would help with that kind of thing. Neither of them would even try to provide any better protection against corruption than if the application program(s) crashed. If a drive failed while applications were writing to files, the files might be current as of the most recent completed system call (write() or whatever), but even then, they could be "corrupt" in the sense that not all the operations in a sequence had completed; I do not think even reiser4 offers that level of transactional support-- I guess maybe it could have some sort of open()...close() atomicity thing, which would be nice.
Larry
If the history of ReiserFS is anything to go by, then backwards compatibility with previous ReiserFS filesystem is not a reasonable expectation. It will have a new block-level format, will not work with old format filesystems, and it will probably horribly corrupt your existing ReiserFS filesystems if you try to use it with new ReiserFS4 filesystems. If it claims backwards compatibility it will do what I have just stated anyway. The worst problems will occur when new and old format partitions are used simultaneously.
You can also expect Reiser to want this entirely new module in Linus' 2.6 branch and probably 2.4 as well, despite its ridiculously untested state. You may even hear about abuse, rudeness, and new GPL violations from the kernel developers, coming loudly from the Reiser camp.
I'm as mimsy as the next borogove but your mome raths are completely outgrabe.
Ext3 in its default mode also does metadata journaling only, but it always writes the data blocks first (at some performance hit), so such lossage won't occur.
In theory, you may lose data badly during a power failure on a non-journaling filesystem such as ext2, since the filesystem itself may be badly broken. However, this does not occur often in practice.
In short, reiser3 is probably not the data-eating monster in normal operating conditions, nor will the filesystem become corrupted in case of a power failure, but newly rewritten data can get lost (including the older versions) during a crash or power failure, so it is probably safer to use ext3 for now if you don't have a UPS. Also, if your disk fails, all bets are off --- expect to lose some data, no matter how advanced your filesystem is (unless it is designed to operate on faulty hardware).
BTW, I dumped reiserfs on my disk (on my home machine) during a disk failure because it doesn't have the feature to mark blocks as "bad". Quite a few blocks on my disk mysterically went bad, and for some reason it was not corrected by the hard drive.
Complete rewrite will support Atomic writing, 2-5 times faster File corruption
Eek! Thankfully on re-reading, I saw that "Complete rewrite will support Atomic writing *and* 2-5 times faster *and* File corruption will be a thing of the past" :-)
Here, here, it depends you know... I've somewhat read some of Reiser's Manifesto (I'm being generous for not calling it a logorrhoic rant ;-) and thought: "Ho, this man really has a cool toy in his hands!" If I remember correctly Hans has a plugin type architecture in mind and gives as an example a filesystem module specifically targeted for /etc/passwd. In this scenario the caller uid restricts the type of information a read requst would provide un-abstracting the filesystem from the data it contained (in this case uid=0 can read /etc/passwd as it is, password hashed included while anyone else can only read it's own record while the other appear as 'shadowed'). Also, it provides an 'everything is a directory' style extended attribute interface so your .jpeg file could have file.jpeg/attr1, file.jpeg/attr2 (say thumbnails), etc... I'm afraid MS has a patent on something very similar but then it all factors down into having a less abstract, more data-type aware database filesystem. So in your case, a reiser plugin (and some patching to the app) would make transactin-like commits to disk; if anything fails, a rollback would return your datafiles to a fully consistent state in a sense relative to your application rather than to the filesystem. Currently a journalized FS only makes shure that your metadata is consistent, that there are no orphaned inodes or inconsistent free maps... if your application file is halfway though a commit and the data within is partly related to the old and new state you're screwed, but the filesystem is happy. A reiserFS module would know how to clean up if the app called a write() (and one only, with all the relative data updates in one big wallop) and failed for any reason...
Mi domando chi à il mandante di tutte le cazzate che faccio - Altan
Where, where?
You mean "Hear, hear".
Also, if your disk fails, all bets are off --- expect to lose some data, no matter how advanced your filesystem is (unless it is designed to operate on faulty hardware).
Can't any filesystem operate on faulty hardware through support of a block device abstraction underneath it? Isn't such support called RAID 5 and part of the mainline kernel?
Everything I read about WinFS sounds like a blatant rip-off of BeFS (The BeOS's filesystem)'s featureset.
BeFS was database-driven and had all kinds of great querying features, could support files of over a petabyte (I forget exactly how big that is), had fixed-size blocks rather than a fixed-count, and I believe it was journaled, too. That was back, when? 1995? 1996?
I bet M$ is glad Be went down, now they don't have to worry about infringing on patents (if BeFS WAS, in fact, patented). Or does Palm own that, now? Or whoever bought all their IP.
...spike
Ewwwwww, coconut...
I was a little unclear. The kernel crashed because of the bad disk. After replacing the disk, rebooting, and replaying the journals, we found Reiser had corrupted data on other, still-good disks. I would certainly expect to lose data that had been scheduled to be written at the time of the crash. I did not expect to have files on good disks essentially shuffled up with each other, which was the form of the data corruption.
I agree that this is a lame post and should be modded down to -1, but offtopic? Seems pretty ontopic to me. Maybe redundant would be a better choice.
The problem wiht reiser is that thanks to it's complicated B-treeish dirs and tail handling you have
litle chances of geting your data back when something happens to the disc. In extX you e2fsck mark badblocks some files go to lost+found or if it fails you can salvage data with debugfs.
In reiser you have no such tools
My friend droped his disc and lost all data.
Reiser is good but if you have a hardware failure in some part of the disc probably you can say your files goodby.
File and filesystem corruption is never a thing of the past. You can mitigate their effects, but no amount of filesystem robustness will fully protect you against failing hardware. Please don't make false advertisements regarding F[L]OSS projects.
The 'atomic update' quality is something MySQL and PostgreSQL can take advantage of, or in fact any lication that often writes small amounts of data and calls fsync/fdatasnc. And it shouldn't be terribly difficult to make the required changed. Kudos!
Mostly that was several dozen mail spool files. Didn't I switch to a journaled file system in part to avoid this sort of thing? Grrrrrrrrrr.
>>>>>>>>>>>>&g t;
No you didn't. Usually journaled file systems only protect metadata integrity. So files will get corrupt, but entire directory trees will never suddenly dissapear. This is true of all journaled filesystems, even high-end ones like VxFS or XFS. Some filesystems (like ext3 and reiserfs) offer data journaling in addition to regular journaling, but at a significant speed hit. Data journaling is usually disabled by default, except in ext3.
The new Reiser4 will support atomic file operations naturally, at the full speed of the filesystem. As a result, you can get the benifets of data journaling without the performance hit.
A deep unwavering belief is a sure sign you're missing something...
IIRC, this was discussed on the ReiserFS lists a while ago.
/usr have corrupted filenames, or that your computer crashes when trying to a read a file.
Basically, ReiserFS does only metadata journalling by default. This means that after a crash your metadata will be good. That is, you're not going to suddenly find out that half of the files in
However, this doesn't guarantee that the contents of the files will be in order. To ensure that you need full data journalling, which is of course slower. I've heard that ReiserFS 4 has transactions that let programs group operations in such a way that the changes get rolled back to the last checkpoint.
"We supported ReiserFS at MP3.com..." -Michael Robertson
Are there other familiar places that use(d) ReiserFS?
By the way, great tag at the bottom of the article:
"Copyright (C) 2004 Lindows.com, Inc. All rights reserved.
Lindows.com is not endorsed by or affiliated with Microsoft Corporation in any way - in fact, we don't even really like them because they are suing us.
Just like how the parents in that new Wendy's commercial named their kid "Junior" after a hamburger...
"Where, where"?
You mean "Here, here"? which is what he wrote...
... and they still have data corruption?
Ouch!
I dunno how much I'll be able to trust this filesystem in the future.
The real situation seems to be that R4 is marginally faster than R3 on the average. And before replying, try checking the data and see for yourself.
I've been using ReiserFS 3 as my primary filesystem for quite a while now, and I'm loving it. I haven't had a single case of corrupted files (unlike with Ext2 and Ext3), and it seems and feels much faster. All in all, it's a very sweet filesystem, and I'm quite sure ReiserFS will be well worth upgrading to.
But since it's a complete rewrite, bugs are bound to happen. Let's just hope they aren't serious.
Eat the rich.
The line only says they "supported" (funded) it, not that they used it.
Bill Gates was quoted as saying, "We are aware of this issue and have added it to the list of features we are including on the backs of the Longhorn(tm) boxes."
...spike
Ewwwwww, coconut...
ReiserFS is good because it uses advanced algorithms and such that I will never understand to increase the speed at which harddrives (or usb solid state devices...) can read and write data at the cost of processor utilization. This is good because
A) Processors have been increasing in speed much more quickly than hard-drives, so this tradeoff can lead to a more balanced system.
B) Hard-drive read/write speeds can have a lot more impact on the speed of a computer than people realize. When large programs (Open Office, etc.) take a long time to load up it makes a computer seem slow, and the general mentality is that the solution to a slow computer is to get a faster processor. Sometimes when I'm booted in Windows XP i'll be running a lot of programs simultaniously and the computer will seriuously bog down, so I'll three finger salute and look at my running processes, only to find that my cpu is idle. I'll then look over to see my HD activity LED constantly lit.
On the other hand, one of the Cons of using ReiserFS is that it eats up CPU cycles. It probably doesn't make sense to use it on an older (Pentium I/II) computer because the gain in Hard Drive speed will be overshadowed by the lost processor cycles, although 2.6's new kernel pre-empting code would probably help a lot with this problem.
There are also reports of file corruption, so it might not be a good idea on a server that can't afford down time to restore a backup.
This message is encrypted with Quad ROT-13 to protect the author's copyright under the DMCA.
i use it on production machines, never had a problem. one of those machines it curently over 400 days uptime, and it does 10,000's of file copies everyday. most of my other machines are between 200 - 365 days up time as well, again never had a problem and this is on 2nd hand hardware. kind of speaks for itself really.
If you mod me down, I will become more powerful than you can imagine....
ext3 was really sold as a fix for all problems and it has turned out to be crap. Ooooooh, it's journaling... woohooo! So was/is NTFS, no body raves about how great NTFS is, atleast not on slashdot.
It's marginally better than ext2, but that's not saying much. I can't even count the number of ext3 file systems I've had trashed in the past couple of months.
I'd give reiser a try if I were you. So far it's been good to me.
scott
Name your daughter reiser and in the later days you may regret it.
Hint: Common things associated with reiserfs or just filesystems. Mount. fsck. hard-drive. etcbr
The only such claim I ever saw said that Reiser had a higher CPU utilization, in percentage terms. But that's just what happens when you spend less time on I/O.
Imagine this benchmark scenario: Filesystem A takes 10 seconds and has 20% CPU usage. Filesystem B takes 2 seconds and has 90% cpu usage. Some would claim that Filesystem B is eating CPU cycles, but in fact it is consuming less processor time! (1.8 versus 2.0 CPU seconds.)
IIRC, the situation with ReiserFS is similar. It uses marginally more CPU time (maybe 10% or so) but the CPU utilization as a percentage seems much higher because it spends so much less time doing I/O.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
"journalized" FS's need to become better at saving the actual data files instead of getting faster and less reliable! Oh yay, Dancing trees... what happens when they all fall down! DOOM! Ive had my whole system "borked" several times because i kept running into software bugs... On several occasions i had to rebuild the tree (from a Gentoo LiveCD) - but it BORKED lots of stuff and made a HUGE lost+found directory filled with juicy anihilated files. When i tried using ext3, it was like molasses in January... what we need, is a decent compromise between speed and reliability!! Nowadays i back my entire system onto a USB2 drive (often), then unmount it (or mount as read only). Havent lost a file since. :D