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.

Re:ext3 to reiser4 ?

[Dwonis]

I doubt it. In general, that's not necessarily possible (though you can get away with it in special cases). In any case, doing that without a UPS would probably be risky, since there would be a (probably very long) period of time where the filesystem is totally incomprehensible to BOTH filesystem drivers (old and new), and if the system dies during that time, say bye-bye to your data.

Re:ext3 to reiser4 ?

[treat]

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.

ext3 has fewer bugs and has been through more testing. ext3 has a functioning fsck, reiserfs does not.

For most applications the reliability of the filesystem is far more important than the performance.

I'm definitely excited about reiser4 but I don't expect to be using it in production systems for years, unless I have an application that specifically requires it. If an fsck for reiser4 is never released, I might never use it.

Re:ext3 to reiser4 ?

[Aardpig]

Would it be possible to copy all data from the ext3 partiton to a network mountpoint(nfs, ftp, samba, etc...) format the drive to reiserfs, and then copy all the data back?

Yes! Some advice, however: if possible, make two separate copies of your data on different remote servers. Also, check the integrity of your copies using something like md5sum -- there's nothing worse than moving data to a new location and finding out it's corrupted only after you have deleted the originals.

Re:Windows port?

[Stevyn]

You're talking about porting a file system assuming the operating system is unaware of it. We can look at the source code and linux and find that answer out, but with windows it's more difficult to tell. Since Microsoft seems to only support FAT, FAT32, and NTFS, I'm sure that's built into the kernel for speed. So unless you're going to make something that emulates NTFS on top of reiser, I doubt it would ever work. And if you're going to do that, what's the point at the end of the day?

For windows and linux compatibility, I always use FAT32. Linux isn't perfectly stable with NTFS and Microsoft only touches microsoft formats (hey, why not?).

Stability

[Anonymous Coward]

I remember reading something a while back about how ReiserFS would occasionally barf and corrupt data... And that the Dev response was something to the effect of 'so what?'.

How stable in this new version in terms of data loss? Is this something that's optimized to run on a RAID array--with, say mirroring--that gets it's speed from dangerous shortcuts that are only acceptable in a non-single-disk environment?

Sweet!

[chizu]

Now when will we see it in the vanilla kernel?

Re:Only one question...

[jrcamp]

Star [fokus.gmd.de] does though.

How reliable is an "unstable 1.0" anyway?

[JavaScrybe]

I have to wonder. ReiserFS does really nice with all the hard-work partitions I have over here, and I'm more than willing to convert (yes, using tar if I must), risking crashes and data losses.

But what crashes/corruptions are we talking about? Will I lose my entire filesystem? Will files randomly disappear? Will it install Windows on my Linux box? (Lords no!)

How tested was this 1.0 release? I have to assume it was "thoroughly but not fully" tested, am I right? After all, why release a 1.0 if you're not ready to "promise" at least basic stability to normal users?

Re:I know everyone's thinking it...

[Elote]

Yeah, of course it won't be as stable as V3 initially, but I just have a problem with them saying that it is "released". If they had said that a "release candidate" had been released or that it had been released to the mm tree(not vanilla yet) then this would have irked me a little less. Saying "it is released" implies a little more than what they meant.

Re:ext3 to reiser4 ?

[WindBourne]

In any case, if you're looking for a really nice filesystem, use XFS. It was developed by professionals (SGI), is fast and stable, and is now released as open source.

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.

Re:ATOMIC FILE-ING SYSTEM HERE I COME

[Brandybuck]

Unless you have *synchronous* atomic commits, you'll still lose data on power loss. And while I think a synchronous atomic filesystem would appeal to a bank, most end users want something a little quicker than frozen molasses.

Re:Custer book

[Ever Dubious]

The Custer book should have been printed with a bright yellow cover and the title "NTFS for Dummies". Mostly, it is a tease of an almost-look at what might have been a really good book.

EVERY computer needs a u.p.s.

[FrankHaynes]

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.

Re:ext3 to reiser4 ?

[ispeters]

I'm not very knowledgeable in this department, but don't all hash algorithms have collisions? There's a hell of a lot of 128-bit numbers, but there are a lot more 256-bit numbers than 128-bit numbers, so hashing two arbitrary 256-bit files could result in the same hash value. And a 256-bit file is pretty freaking small, so hashing any two arbitrary files could, potentially, result in a collision, no?

Ian

Re:Stability

[Wesley Felter]

If your filesystem has bugs, no amount of RAID will save you.

This looks very cool.

[squidinkcalligraphy]

This looks very cool.

Using files are both files and directories is really nice - throw ACLs, metadata, whatever in a directory the same name as the file: access it as a file and it is the file, access it as a directory and it provides access to the metadata. It doesn't break things. Well, not much. As mentioned, this will break things like tar a bit. But the VFS has managed to deal with resource forks from HFS, albeit in a slightly ugly fashion. This is a little nicer, and perhaps with time will be the framework for slowly abandoning outdated filesystem concepts.

How would you mofidy tar to deal with this? Add a .reiser_meta folder in each directory to store the corresponding file directories? Or is there another way?

Re:Transactions?

[ceswiedler]

Reiser4 implements a resier4() syscall with new semantics for their custom operations. That's the interesting thing about this; they're adding onto the Unix APIs. Therefore (from a syscall standpoint at least) they can do things like transactions which open() and write() can't support. Of course, this comes at the expense of compatibility with other filesystems, but if it works as advertised, I'd have no problem writing code which takes advantage of it.

Filesystems seem to be like VWs

[mcrbids]

There are two kinds of people, when it comes to the original VW Beetle: Those who love them, and those who hate them.

People who do not fall in one of the above two categories have never really used or owned an original VW Beetle.

It seems filesystems are the same way. I'm a long-term Ext2/3 user and have never had any particular issue with it. For the medium-power stuff I work with, it does fine. The filesystem on my laptop has been ext2/3 for almost 5 years now, I still have email, documents, etc. from 5 years ago on it. (It's been copied a few times - it originated on an AMD K6 system, now it's on a Dell Centrino Laptop)

So, I guess I'm in the "Ext3 is all good" camp.

Reading these posts, there are those who love Reiser, and those who hate it. Those in the middle haven't apparently used it.

I've found Ext3 to be slow when you have more than about 5000 files in a directory. If I had a specific need for that, I'd consider Reiser if my particular distro (RedHat migrating to Debian) supported it "out of the box".

Other than that, why bother? I've delivered millions upon millions of email messages and many millions of website hits on servers running Ext3.

So, for me, what filesystem I use is sort of like what tires I use on the car. I might care slightly when installing, but otherwise I wouldn't give even a rat's ass.

Re:Helpful Mirror

[PingXao]

"Reiser4 is architected for military grade security."

DING * DING * DING * DING

Alarm bells going off here. There is no commonly accepted definition of what constitutes "military grade security". Authors and vendors should avoid this terminology like the plague. It reeks of snake oil and most security profressionals will look askance at anything that touts this "feature". Having said that, I've used Reiser3 and I think it's great. There's no reason to think Reiser4 won't be even better. Given its plugin architecture there's also no reason to think that secure plugins can't be developed for it in a transparent way that actually provide good security. Maybe my complaint here is pedantic. Never say never, but no software program should ever use the phrase "military grade security" if it wants to be taken seriously. There is no standard of "military grade security" by which such claims can be measured. Why would you want your software to be grouped with fraudulent security products, even if yours really is secure.

Re:Helpful Mirror

[JamesKPolk]

When you're being paid by the military and being told what their needs are, you can say military all you want.

Re:ext3 to reiser4 ?

[Wavicle]

Because I can show you a collision in MD5. It's not that hard.

# echo "There's gold in them thar hills!" |md5sum
208b337f8c1a507ffd9fdf39e6178edb

There's a message and its hash. If it isn't that hard, produce a collision. Preferably one that could potentially be either a corrupted version of the original or a malicious alteration. After that we'll see if it is truly "easy" to produce something similar embedded in a .tar.gz file.

Re:ext3 to reiser4 ?

[kimba]

Apparently, Omnifarious is stubbornly concerned that someone might hack into this guy's computer when he is transferring from ext3 to reiser4, spend significant (hypothetical even) resources in generating identical files that have the same md5 sum in the brief window of opportunity before the file transfer is complete. And what would be the attacker's gain? Nothing more than pissing this guy off by having a couple of corrupted files.

Yes, MD5 collisions have been shown. That has NOTHING to do with the problem at hand regarding checking file corruption when transferring between two disks. The argument that MD5 should be abandoned for this purpose is ridiculous.

Windows vs Linux: encrypted filesystems

[0x0d0a]

There are also some severe disadvantages to block-level encryption -- from a user standpoint, WinNT-style filesystem-level encryption is generally preferable. Among other things:

* Filesystem-level encryption can outperform block-level encryption.

* It's easy for a Windows NTFS user to "start encrypting something" -- they right-click a directory and check a box. Linux requires a new mounted filesystem running through a new loopback device. Since this isn't doable at the user level in any distro that I'm aware of, it pretty much means that each user doesn't have their private files encrypted separately.

* Choosing as-needed performance is not trivial. I currently maintain individual files encrypted with GPG. I don't want to have to have my P2P software making my kernel blow cycles constantly and unnecesarily encrypting and decrypting software.

* Unless I'm doing something really grotty, like putting a filesystem on block-level encryption on an LVM virtual volume, if I'm using block-level encryption, I'm forced to choose how much space to allocate to each encrypted area -- how much to put towards my ~/.private directory, how much to put in my ~/main/notes/passwords directory, and so forth. If I'm using filesystem-level encryption, I'm taking available space from a shared pool.

* While not strictly a block-level vs filesystem-level encryption issue, no major distro that I'm aware of provides a nice interface for setting up encrypted directories (well, mount points with block-level encryption) and home directories, with a user's login password used to decrypt keys used to access the encrypted filesystems. Windows is significantly more user-friendly (including providing the option of administrative key recovery) here.

The block-level approach is ideologically clean and modular, but has serious drawbacks. It cannot replace filesystem-level encryption.

Re:ext3 to reiser4 ?

[boaworm]

This is the danger of ext3 journaling (and possibly others as well). It makes people beleive that just because the filesystem passed as "clean" during boot, no corruption occured. Try a full fsck after a year or so of running (with a number of power failures/OOPS'es), and you will probably find a number of ext3 fs corruptions not detected by the "fast" fscking.

As far as reiserfs is conserned, bring me quota and i'll consider it. Until then, it's ext3 with full fsck's at boot.

Re:ext3 to reiser4 ?

[Anonymous Coward]

Great! Now let's just wait a few years until "original corruption problems with reiserfs 4" are well in the past, too, and we can start using it.

You're missing an important point, which is that so far there haven't been any reports of corruption with Reiser4.

Your attitude is a bit like saying that you'll never touch Linux 2.6 because of those problems early in the 2.4 series. Like, WTF?

Re:Helpful Mirror

[zmooc]

How does your test tell us anything at all about the speed of the filesystem? I think it tells us more about how many times you can fork() touch in a certain amount of time:P

Re:Reiser blew it with me.

[Anonymous Coward]

Honey I just saw a plane crash. I'm *never* going to fly again.

I just got sunburnt. I'm never going sunbathing again.

I just got in a car crash. I'm never driving again.

I just fell off a ladder. I'm never climbing one again.

I just watched the twin towers fall. I'm never going to trust a Muslim again.

Ad infinitum, ad nauseam. Honestly.

Re:Who's got the balls...

[justins]

I'm not surprised that RedHat did what they did - it's the problem of limited ressources.

Read what Hans wrote again. Shipping their kernel with REISERFS_DEBUG turned on isn't a question of limited resources, it's a deliberate attempt to undermine the performance of Reiserfs on that platform.

(and yes, I've read the excuses for this, and no, I don't use reiserfs, so it's not like I'm carrying water for them, but Redhat's behavior in this regard has been awful)

Re:ext3 to reiser4 ?

[Anonymous Coward]

Yes, but remember Reiser4 is a complete rewrite. There is no basis for extending the trust for Reiser3 to Reiser4, especially as the immature Reiser3 was unstable.

Re:Filesystems seem to be like VWs

[metamatic]

There are two kinds of people, when it comes to ReiserFS: people who love it, and people who have tried to run it on RedHat.