Slashdot Mirror
Reiser4 Filesystem Released
trixie_czech writes "It's finally arrived. Go to namesys for reasons to use reiser4 as a filesystem and benchmarks. Go here to download. Enjoy!" The Namesys homepage in its current stage reminds me of a cross between The Secret Guide to Computers and the GNU Manifesto -- which is to say, there is a lot to read here, not just a bullet-pointed feature list.
... but can they tango?
Will I be able to convert my exsisting ext3 fs to reiser4 fs withou having to reformat?
No, you will have to reformat. However, I recommend the upgrade; I've seen a number of studies showing that the performance of ext3 is awful compared to reiserfs. The only arguable advantage of ext3 is its compatibility with the baseline ext2.
Tubal-Cain smokes the white owl.
there is rfstool for reiserfs (afaik not v4)
and many for ext2/3
if OTOH, you are looking for a fully featured driver that can be used for production use, then i wouldn't count on it
Marge, get me your address book, 4 beers, and my conversation hat.
Possibly using convertfs, but I have no idea if it works or not.
This page seems to have more info about it.
Well, Mr. Reiser Dude suggests tar in his posting to lkml which can also be viewed on kerneltrap.org.
In other words,
no.
yeah, that, and *stability*. reiserfs has a noteable history of people losing their data because of filesystem problems.
Not over the past couple of years -- the original corruption problems with reiserfs, although pretty severe, are well in the past now.
Tubal-Cain smokes the white owl.
IF you can get to the site, you'll find this juicy reference at the end:
[NTFS]
"Inside the Windows NT File System" the book is written by Helen Custer, NTFS is architected by Tom Miller with contributions by Gary Kimura, Brian Andrew, and David Goebel, Microsoft Press, 1994, an easy to read little book, they fundamentally disagree with me on adding serialization of I/O not requested by the application programmer, and I note that the performance penalty they pay for their decision is high, especially compared with ext2fs. Their FS design is perhaps optimal for floppies and other hardware eject media beyond OS control. A less serialized higher performance log structured architecture is described in [Rosenblum and Ousterhout]. That said, Microsoft is to be commended for recognizing the importance of attempting to optimize for small files, and leading the OS designer effort to integrate small objects into the file name space. This book is notable for not referencing the work of persons not working for Microsoft, or providing any form of proper attribution to previous authors such as [Rosenblum and Ousterhout]. Though perhaps they really didn't read any of the literature and it explains why theirs is the worst performing filesystem in the industry....
Nope convertfs won't work... From the horses mouth:
To upgrade from reiserfs V3 to V4, use tar, or sponsor us to
write a convertfs.
The lkml posting is probably cached all kinds of places, but kerneltrap also reproduces it in full.
Then again, reiserfs v4 and v3 have nothing to do with each other (unlike ext2 and ext3 for instance), so there's no quick fix possible probably.
On the other hand - reiser4 is completely untested (compared to reiser v3 and jfs, xfs, ext2, heck even the wine-dll emulation layered ntfs writing driver...), so do yourself a favour and don't do anything quite so crazy as not just using it for a production machine but also trying to convert an existing system to it with 'smart' tricks... Give it a little while... or make a lot of backups...
>MD5 has been proven to have collisions.
Statistically speaking you are more likely to get malaria in Arizona than experience a random MD5 collision.
I'm going to stick w/ Emacs for my filesystem thank you.
Um, yes, there is an advantage. That's what the journal is for (duh.)
It astounds me that your post was marked as "Informative," because it's downright wrong.
Now, if you're talking about fsck after a certain number of boots, or a full fsck for whatever reason, then no, there's no advantage over ext2. It's ext2 + improvements + journal, for the most part.
For my money, using ext3 without btree hash dirs is stupid nowadays. Go back and bench reiser vs. ext3. ext3 is usually still slower, but the gap is narrower nowadays.
Stating on Slashdot that I like cheese since 1997.
Err, the point of atomicity w/ journaling in a heirarchical system is that if you lose power during a write, it is data to which no parent i-node or directory points. The data being created or altered is written first, then its updated directory, and then its parent directory on up to the root. Or you have one journal level, where the file is written to journal and then the journal entry is copied over the original location. If power dies when the journal is being written, data is lost but the FS maintains integrity, or if the power goes during the copy, the journal exist. Atomicity means that a transaction either happens all the way or not at all, and Reiser4 does guarantee this. In-flight data can be lost so long as partially written data does not leave the system or some other API-level atomic transaction partially completed.
When deciding which filesystem would be best for our first critical samba file servers, this post and other scattered rumors of unreliability scared us away from reiser3 for the time being:
u ly/msg00418.html
;)".
http://www.redhat.com/archives/fedora-list/2004-J
The date of the post caught my eye. The test was very recent. Ext3 won in this particular case, by a longshot, leading a Red Hat employee to respond "Your investigation proves that we default to the right mode
I haven't seen ext3 (ordered) lose in any reliability benchmarks versus jfs, xfs, or reiserfs, though it's hard to find many such benchmarks.
"man reiserfsck"
But ReiserFS doesn't need an "fsck" type program in normal circumstances. In power outages, etc., it's rock-solid. But for things like drive failures and the likes that tend to actually corrupt the data, then yes; EXT3 is the better choice. The reiserfsck program isn't intended to be run on the event of just any power outage or failed unmount, because those sorts of things don't tend to damage the filesystem.
I've been using ReiserFS 3 for years and I've really been happy with the results. The only times (once or twice) that I've had problems were when I had severe hardware malfunctions (due to failing mobo capacitors and a dying hard drive), and my own carelessness when trying to repair the bad data.
Ok, so thats the standard response, but the main benefits will be stuff like: encryption plugins (so easy per directory encryption).. Finally maybe we'll have fully encrypted home directories easily. and stuff like the winFS system integrated into the filesystem possibly. its also 2X faster then reiserfs, and 4X faster then NTFS The big issue though is that until freebsd gets these benefits, apps aren't likely to get these capabilities :(
so maybe someone should work on porting this, then maybe theres a good chance these technologies will be used extensively..
And Reiserfs (and for that matter, Linux kernel) is not developed by professionals? Reiserfs is fully funded and the designers/coders are paid; By definition, PROFESSIONAL. But they are also talented
I suppose it's just a coincidence that the reiser benchmarks page doesn't compare it to XFS... or maybe they were too embarassed to show the results?Please quit being a total twit. XFS has its' place, but for now, we are discussing ReiserFS. Just for the record, ReiserFS has been around for years, and does a great job with mixing loads of little to medium files. While XFS does an ok job, it really excells with the large files, in particular, very large sparse files.
For what it is worth, I have used Reiserfs, XFS, JFS, EXT3, EXT2, and minix for linux FSs. I have found that they all have advantages depending on what you are doing. minix works for compatability (with very OLD linux); Ext2 does a great job with a mostly read only fs (think boot or /usr; Ext3 has the advantage of data journaling, but it is soooooo slllloooowwww; Jfs, XFS, and Reiserfs are my main ones and they always work.
I prefer the "u" in honour as it seems to be missing these days.
It hasn't been my experience that ext2 or ext3 filesystems are more reliable than ReiserFS. At least, not where I work (I only run ReiserFS at home).
Over the past year, we've had some fairly serious filesystem failures on some of our DB and large FS servers. Ext3 on failed in every instance, Reiser was recoverable (similar RAID/hardware/useage/failure).
We pound the living hell out of our machines, day and night, with billions of small files every year. ReiserFS makes Linux work for us.
There are some instances where ReiserFS v3 is slower than Ext3, but we don't care about that any more. We're finished with Ext2/3, and are looking forward to testing ReiserFS4 now that it's been released.
I've successfully recovered a trashed array running ReiserFS after losing a CPU.
reiserfsck is there, and does work.
I've had more problems with the Ext filesystems than I care to mention, and we do not use Ext2 or Ext3 on any production machines that run Linux any more. Everything's ReiserFS v3, and once we start testing Reiser4, we'll move to that.
Ext3 was a hack for compatibility with Ext2. It serves its purpose, which is easy upgrades and backwards compatibility.
Write on the blackboard 10^10000000 times:
"EVERY computer needs an uninterruptible power supply. EVERY one."
There are so many problems of which you might not be aware, aside from those requiring you to run fsck afterwards, which are solved by a good u.p.s. that you'd be penny-wise, pound-foolish for not putting a u.p.s. on every machine in sight.
My clients think that I can walk on water simply because I eliminated a large share of unexplainable wierdnesses from their machines by installing an inexpensive u.p.s. on every single one.
Solid, clean power is very important to a stable computing system. I cannot stress this enough.
slashdot: A failed experiment.
I myself have never had any problems with reiserfsck -- what exactly is wrong with it?
You don't know? The problem with reiserfsck is that it is invisible to those who are dogmatically anti-Reiser. Hans is currently working on a ReiserDecloak() function to address this.
I suppose it's just a coincidence that the reiser benchmarks page doesn't compare it to XFS... or maybe they were too embarassed to show the results?
---
Please quit being a total twit. XFS has its' place, but for now, we are discussing ReiserFS. Just for the record, ReiserFS has been around for years, and does a great job with mixing loads of little to medium files. While XFS does an ok job, it really excells with the large files, in particular, very large sparse files.
I just wanted to add my two cents to this: We had done internal benchmarks at our company, and found XFS to be the fastest filesystem, and seemed to have a good track record with the community. (We didn't consider reiserfs because of its lack of bad block handling).
Either way, we converted ONE of our 2 Terabyte mount points to XFS. Whenever a file would be created on that mount point that exceeded 4G, bdflush would peg the cpu at 100%, commits to the disk would cease, and file system corruption ensured.
This was with kernel 2.4.23.. The problem was fixed in 2.4.25 (maybe 2.4.24, but we never tested that kernel). When we had this issue, and linked it to XFS (through another test system), we quickly migrated away from XFS, back to ext3.
We never had a problem like that was the ext's. We've lost data with both reiserfs and XFS. And if you grep the changelog for the kernels on XFS, you'll see tons of fixes for "deadlocks, race conditions, oopses", etc. These were all fixes AFTER 2.4.23..
Lesson: Stop playing with something that works, and be happy your servers serve. We never made it to testing JFS, and we probably won't. Ext3 might not be the fastest kid on the street, but it has been the most reliable for us.
-- If we don't stand up for our rights, now, there will be no right to stand up for them later.
Journaled: The data is written to a temporary queue and then copied to the main storage. If the system dies while writing to the temporary queue then the main storage is unaffected; if the system dies while writing the queue to main storage then the system will notice when it reboots and will resume writing the queue to main storage.
PRO: Safer than non-journaled since you can never end up with half a buffer written to disk.
CON: Writes everything twice, causing delays. Very bad things could happen if data and associated metadata are in separate transactions and the system crashes between them.
Atomic: The file data is written to unallocated space on the disk. Once that has completed, the directory record is updated by writing a copy of that record to unallocated space. The directory's parent is then updated by writing *it* to a new region of the disk, and so on up the tree. Since each write doesn't take effect until the next has completed, any interruption results in complete reversion.
PRO: Safe. Faster than journaled since there is no double-posting.
CON: More complicated to impliment, I suppose. I would expect it to be slighly slower than journalled method when writing very small changes to existing files as journalled can optimise the writes in the queue whereas atomic has to finish what it started...
When you're being paid by the military and being told what their needs are, you can say military all you want.
Our atomicity does not provide isolation or rollback, it is only atomic in the sense of whether it survives a crash. That is, a reiser4 atomic set of operations will either all survive the crash or none of them will.
You can say that this is not really atomic, and by database traditions that is correct, but I believe we have implemented the aspect of atomicity that for sure should be implemented by the file system and not by the layers above.
Later we may support more isolation and rollback, but we started with allowing people to define a set of fs modifying operations that would either all be preserved across a crash or none of them would be preserved. I tried using the term "transcrash" instead of atom, but no one but me loved the term.
I must caution though that the API for defining an atomic set of filesystem operations is still being debugged. The core infrastructure is rock solid though, as it is what we use for atoms defined internal to the FS. We shipped as soon as our core code was rock solid, and plan to incrementally finish the other stuff over the coming year.
Keep in mind that redhat kernels are highly patched and they don't apply reiserfs bugfix patches out of a deliberate policy to exclude them (yes, we offered to supply them but were rejected), so we don't recommend the use of redhat kernels for reiserfs, we recommend the official kernel, or the SuSE kernel.
RedHat are the guys that at one point shipped their kernel with REISERFS_DEBUG turned on just to make us look slow.....
I don't know why RedHat regards us as in the enemy SuSE camp just because we took money from SuSE, we would take money from RedHat too if it was offered....;-)
These distro rivalries are distasteful to me.
Hasn