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.

Comments

COOL!

[Anonymous Coward]

need I say more? head for the mirrors!

reiser

[Anonymous Coward]

I for one, welcome our new, fourth-generation, filesystem overlords.

ext3 to reiser4 ?

[Anonymous Coward]

Will I be able to convert my exsisting ext3 fs to reiser4 fs withou having to reformat?

Re:ext3 to reiser4 ?

[Aardpig]

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.

Re:ext3 to reiser4 ?

[HermanAB]

No, sorry, but it is worth the change. It is like buying a new faster computer.

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 ?

[David M. Andersen]

Possibly using convertfs, but I have no idea if it works or not.

This page seems to have more info about it.

Re:ext3 to reiser4 ?

[Coneasfast]

true that, also in ext3 there is no such thing as fast fsck after bad shutdown, i have tested myself and the improvement is little to none over ext2.

OTOH, reiserfs is very fast in this department

Re:ext3 to reiser4 ?

[Anonymous Coward]

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?

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 ?

[timmyd]

The only arguable advantage of ext3 is its compatibility with the baseline ext2.

yeah, that, and *stability*. reiserfs has a noteable history of people losing their data because of filesystem problems.

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:ext3 to reiser4 ?

[Aardpig]

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.

Re:ext3 to reiser4 ?

[Anonymous Coward]

It would theoretically be possible to copy your old partition into a newly formatted partition, however you need to take into account that your init scripts would probably be confused, at the very least.

Re:ext3 to reiser4 ?

[Tyler Eaves]

Care to back that up? When ever someone mentions data loss from ReiserFS it's always "other people", "a friend", etc. I've been running ReiserFS on a number of machines for several years, never had the slightest problem with it.

Re:ext3 to reiser4 ?

[Aardpig]

ext3 has a functioning fsck, reiserfs does not.

I myself have never had any problems with reiserfsck -- what exactly is wrong with it?

Re:ext3 to reiser4 ?

[shish]

in ext3 there is no such thing as fast fsck after bad shutdown

AFAIK, with journalling, there shouldn't be *any* fsck after a bad shutdown - with the few times I've pulled out power cords, I've never seen an ext3 fscking.

Then it seems that reiser spends about a second doing a fast fsck every boot, whether is was shut down cleanly or not...

Re:ext3 to reiser4 ?

[EMN13]

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...

Re:ext3 to reiser4 ?

[Anonymous Coward]

>MD5 has been proven to have collisions.

Statistically speaking you are more likely to get malaria in Arizona than experience a random MD5 collision.

Re:ext3 to reiser4 ?

[gordyf]

Um, every hashing algorithm has collisions. There are more things to hash than there are resulting hashes.

Re:ext3 to reiser4 ?

[EMN13]

All hash functions have collisions; that's not the point... It's extremely unlikely for one to occur non-maliciously. The MD5 collision found was only found after some trivial mathematics done as a matter of principle by your network card just to spite you (okay, just kidding).
It's still perfectly fine to use MD5 to check the validity of your files for bit-errors. Then again, so is CRC32.
I do have a question to anyone more knowledgeable in MD5's weakness: although MD5 can now be spoofed , it's not clear to me from reading the news - is it only directly applicable to messages of a certain type/length or to all messages?

Re:ext3 to reiser4 ?

[1000StonedMonkeys]

Sure MD5 has been proving to have collisions, but that really isn't news. All hash algorithms have collisions simply because of the nature of what they do.

Suppose you've got a 1K file. There are 2^1K possible values that file can assume. If you map those 2^1K values to the 2^160 values a SHA1 hash can assume, you have an average of 2^944 1K files that collide on any give SHA1 hash.

What differentiates hash algorithms is their ability to prevent people from generate a text that matches a given hash. It is currently not possible to do this for either MD5 or SHA1. It has been speculated that MD5 is nearing the end of it's life in this regard though. I don't follow the field closely enough to weigh in on the matter, but I can tell you that the only thing that finding an actual md5 collision will do is demonstrate what was rather easily proved in the previous paragraph.

As far as verifying files is concerned, the cryptographic strength of the hash algorithm is irrelevant. Unless you suspect someone will be tampering with your results, use whatever algorithm you can find a useful tool for, be it md5, sha1, or even crc32.

Re:ext3 to reiser4 ?

[secolactico]

I've been running ReiserFS on a number of machines for several years, never had the slightest problem with it.

I'll say. In fact, my Suse install recommended Reiserfs, so I chose it. Haven't had any problem so far, and I've been merciless with that install (I was asked to evaluate a possible replacement for Windows for our company, so I'm trying to figure ways our users could break things up).

Re:ext3 to reiser4 ?

[menscher]

I gained a healthy fear of ReiserFS a while back when it had some issues with playing nice with NFS. Basically, if I created an arbitrary link in my home-dir, it would sometimes screw up and the destination of the link would be the contents of someone else's file. A file which I do not have permissions to read. Needless to say, it's not hard to hack up a while loop that creates links and then does the ls -l and saves the output for later perusal.

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.

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?

Re:ext3 to reiser4 ?

[1000StonedMonkeys]

Er, 2^864 (that's what I get for trying to do math in my head)

Re:ext3 to reiser4 ?

[Lisandro]

EXT3 sucks compared to (almost) every other filesystem in everything but one thing: it's stability. I've lost data to ReiserFS in the past, but i've *never* lost a byte under EXT3, even under extreme conditions.

I still want to see what the fuzz is all about though ;) I'll be installing it on a spare HD this week.

Re:ext3 to reiser4 ?

[EMN13]

It is now possible to generate a bitstream that matches a given MD5 hash. It's recent news too...
Some postings can be found here, and google is your friend :-).

--Eamon

Re:ext3 to reiser4 ?

[13Echo]

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

"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.

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:ext3 to reiser4 ?

[FooAtWFU]

This is hearsay, mind you (think I found it in the manual for Gentoo at some point, comparing filesystems), but I hear that XFS isn't too good for ordinary computers' filesystems, because it "agressivele caches data in memory", which means that in the event of a system power failure or other crash, you lose a LOT. You apparently should have a good UPS with it.

Re:ext3 to reiser4 ?

[grasshoppa]

I've had issues with it. I had put my camera pictures on it, having used reiser for a while no problems.

Then, a power outage or two later, and the partition was mountable, but had severe data corruption.

Fortunately, I learned years ago about the importance of backups. :)

Re:ext3 to reiser4 ?

[jasoneyre]

I'll bite... Every hashing algorithm has collisions. Even SHA-1. It just has "less" collisions (infinities are strange) than MD5. XeeRz, Jason

Re:ext3 to reiser4 ?

[Anonymous Coward]

Crap, I'm in Arizona

Re:ext3 to reiser4 ?

[Lshmael]

You must be referring to section 4d in the Gentoo Handbook:

XFS is a filesystem with metadata journaling which comes with a robust feature-set and is optimized for scalability. We only recommend using this filesystem on Linux systems with high-end SCSI and/or fibre channel storage and an uninterruptible power supply. Because XFS aggressively caches in-transit data in RAM, improperly designed programs (those that don't take proper precautions when writing files to disk and there are quite a few of them) can lose a good deal of data if the system goes down unexpectedly.

Incidentally, the Handbook is very pro-ReiserFS (although it also says ext3 is "an excellent filesystem," reiserfs is used as the default filesystem in all of the examples). If you spend time on the Gentoo Forums, you will find a number of people who claimed reiserfs tried to kill their computer, and an equal number who swear by it.

Re:ext3 to reiser4 ?

[SaDan]

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.

Re:ext3 to reiser4 ?

[ePhil_One]

It's true tho that a full *forced* fsck takes just as long on ext3 as it does on ext2...

Its also true that by default after 6 months or 30 mounts an ext3 volume *will* perform a full fsck. This can be very painful if the volume is large enough/holds enough files that an fsck will take 24 hours plus (I've seen this several times)

Personally, I'm a fan of IBM's jfs. I had some early problems with it but they were real responsive to every issue I found while punishing it as an NFS volume in a test system.

Re:ext3 to reiser4 ?

[Anonymous Coward]

" I've seen a number of studies showing that the performance of ext3 is awful compared to reiserfs."

A) not always in real world tasks, and B) set ext3 to data=writeback and try again. You SHOULD note that during many of his own benchmarks when ext3 was performing the same level of journaling that reiser v3 provided ie data=writeback, ext3 was in Faster in many cases. In fact in his last set of tests when ext3 is setup to journal the same way reiserfs v3 did, ext3 soundly beats it except in the delete category. Why so many reiserfs advocates ignored the fact that ext3 was in fact not the slug it has been made out to be over and over for years I'll never know. Now you know why we all were not running reiser for the past several years and were somehow able to "suffer" with ext3 "performance" compared to reiserfs.

Lastly ext3 also is out and out more stable and reliable than Reiserfs. That's just the way its been. Honestly I hope that reiserfs v4 crushes ext3 and every other journaling fs out there. I hope its the fastest and most reliable fs every made. But let's just not rehash old fud that wasn't even true and all jump to a new unproven fs until its proven stable for a bit.

Re:ext3 to reiser4 ?

[1000StonedMonkeys]

Thanks for the link. I actually wasn't aware of that particular attack. I'm still not sure that it means that's it's possible to generate a message with a given hash though. The attack presented talkes about generating two messages, M and M' such that M and M' have the same md5 hash. This is a potential problem, but it's still a step away from being able to generate a message that matches a particular hash.

Re:ext3 to reiser4 ?

[Anonymous Coward]

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.

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:ext3 to reiser4 ?

[antiMStroll]

ReiserFS 3 wasn't too solid when Nvidia drivers locked my machine up exiting X-windows to a shell. It blew out my XFCe config files every time I shut down. Can't speak for 4 but I'm in no rush to try ReiserFS again for a very, very long time. XFS never did this to me.

Re:ext3 to reiser4 ?

[ESqVIP]

use whatever algorithm you can find a useful tool for, be it md5, sha1, or even crc32

Jeez, you just made me wonder: is it some kind of requirement to place a number at the end of every widely used hashing algorithm? Maybe it's the key to success we've all missed!

Re:ext3 to reiser4 ?

[zenyu]

When ever someone mentions data loss from ReiserFS it's always "other people", "a friend", etc. I've been running ReiserFS on a number of machines for several years, never had the slightest problem with it.

I lost some data on a ReiserFS partition that went bad. Nothing that wasn't backed up, but it was still a PITA. It was scary because it was silently eating my files, it wasn't like the ext2/FAT problems I was used to where fsck told you something useful. This was years ago, and I've had ReiserFS partition last 2 years now on a laptop without problems.

Re:ext3 to reiser4 ?

[vocaro]

Unless it is a perfect hash, of course.

Re:ext3 to reiser4 ?

[macz]

Joux has apparently proved (though no utilities are out yet) that you can:

Create a file with a pre-determined hash, and do so in a computationally feasible way (rumor has it: using _only_ 2^40 calculations...)

That is it. This means that at compute time you can MD5 a file and get its hash, and then create a garbage binary file with the same hash. In just 2^40 steps.

Big Damn Deal.

One thing that is interesting from a performance standpoint is that MD5 is great for keys (provided you don't have a rogue admin with a lot of time on their hands and heretofore unreleased MD5 hacking utilities), but MD5 is terrible for indices. Since MD5's are absolutely random there is as much chance as an MD5 being next to another as 2^128 key spaces away.

Re:ext3 to reiser4 ?

[zurab]

But for things like drive failures and the likes that tend to actually corrupt the data, then yes; EXT3 is the better choice.

And how do you say this? I personally have used ReiserFS on a bad HD (Deathstar) that trashed my filesystem more than few times (before I found out the cause). I have had to reiserfsck every time and did not lose any data.

Re:ext3 to reiser4 ?

[ultranova]

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.

Doesn't Linux have any byte-by-byte comparison tools ? It seems like a total waste to compute MD5s to compare two local files...

Re:ext3 to reiser4 ?

[hpavc]

Collisons are that frequent? My thinking is that its more likely everyone in Arizona gets malaria in Arizona than a collision on files in a single directory.

Re:ext3 to reiser4 ?

[Short Circuit]

For any two files, sure. But ff you have hundreds of thousands of files, the likelyhood goes up by that much.

My statistics are rusty...anyone want to work the problem? Say with 2, 10, 100, (10^[3..6]) files?

Re:ext3 to reiser4 ?

[Anonymous Coward]

Would I perceive an increased performance on a desktop system if I changed to reiser4?

Re:ext3 to reiser4 ?

[Anonymous Coward]

However, there are applications for which *any* known collisions are undesirable.

Take, for example, a "promise" protocol, whereby I choose a number, expose the hash of the number, but I reveal the actual number only later on in the protocol, such as when simulating fair dice throws with no trusted third party. If I, the attacker, know a collision that the other party does not know, I expose the common hash, then when the other party reveals their number, I get to choose which of the numbers that produce the same hash I reveal as starting number. Therefore, I gain an unfair advantage (typically, the "plaintext" numbers are combined to produce the dice throw).

I don't remember the exact details too well, but I think such an attack might defeat the first version of Rivest's Peppermint system for micropayments. But I'm not that sure about this one.

More worrying is the fact that being able to find collisions in a hash function is believed to indicate fundamental weaknesses in the hash function. More serious attacks against MD5 and SHA1 could be right around the corner.

Re:ext3 to reiser4 ?

[Aardpig]

Doesn't Linux have any byte-by-byte comparison tools ? It seems like a total waste to compute MD5s to compare two local files...

Yes, it does -- diff. However, the point here is that the files aren't side-by-side; one is on the local machine, and the other on a remote server. Hence MD5.

Re:ext3 to reiser4 ?

[macz]

SHA1 has its issues too. Biham and Chen found collisions in a reduced round version of SHA-1 (40 instead of the full 80 rounds). It is unclear whether this can be extended to the full SHA1 algorithm. The NSA is in a tizzy though.

It still takes like 2^51 or 2^80 operations to brute force any of these little nuggets though.

It should be clear that ALL HASH FUNCTIONS HAVE COLLISIONS!

Unless there is a 1:1 correspondance to the key length and the bitstream length there is a chance that any 2 arbitrary bitstreams will generate the same hash. The question is whether this is easy (like CRC32) or hard (like panama, or SHA-512)

MD4, MD5, HAVAL-128, RIPMED, SHA-0, SHA-1 and many others have all been eventually found to have ways of detecting and creating arbitrary collisions (more or less). The question is, is this computationally feasible?

Most of the time: Not without a damn supercluster, no it is not.

Re:ext3 to reiser4 ?

[minion]

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.

Re:ext3 to reiser4 ?

[Anonymous Coward]

Yes, it's true. No fast FSCK. But you wouldn't expect that from a true journal filing system anyway.

Just disable boot time FSCKs, and enable an FSCK at some interval you feel comfortable with. I've tried, with this configuration, to foul an EXT3 fs many many many times. Even as much as cold power off during a write operation, multiple times. It cleans up damaged innodes at boot time, recovers the journal, and continues booting happily. FSCK later, and you'll discover that not much has went awry, and the file system is still intact...

Try it out on a test box. It's truely the only way to go if you're using EXT3, in my opinion.

Re:ext3 to reiser4 ?

[Omnifarious]

So, show me a collision in SHA1. I dare you.

Re:ext3 to reiser4 ?

[MyHair]

man tune2fs

Re:ext3 to reiser4 ?

[arodland]

The point is non-random collisions. MD5 has been proven to have at least some weakness, and there's no reason to expect more won't be found in the near future, now that the methods have been developed.

Some info

Re:ext3 to reiser4 ?

[MyHair]

Statistically speaking you are more likely to get malaria in Arizona than experience a random MD5 collision.

Looks like I picked the wrong week to stop sniffing glue!

Re:ext3 to reiser4 ?

[Anonymous Coward]

And hey, if you can match file sizes and hashes, you're more likely to die of a rabid penguin bite to the left testicle--as a female--in the middle of the Saharah desert than have a hacked file.

There's simply no way that can happen except for in some case that there are two unimaginably large datasets.

Re:ext3 to reiser4 ?

[Omnifarious]

I don't trust any hashing algorithm in which there are demonstrated collisions. You shouldn't either. Stop recommending anybody use MD5 when there's a perfectly good replacement available that practically everybody who has MD5 also has.

I wouldn't be surprised to discover that the fact that you can generate collisions in the algorithm means that its distribution for random input is far from flat, and it's probably a bad idea to use it for anything.

Re:ext3 to reiser4 ?

[arodland]

The point is not that md5 has collisions; that's a matter of "duh". The point is that methods are now coming to light which allow an attacker to find a collision with less work than a brute-force search would require. Which means that now MD5 is less secure than its output length (128 bits) would lead you to believe. Granted, the current attack is not especially applicable to much of anything, but there's no reason to expect that further ones won't be developed now that the foundation is laid.

Re:ext3 to reiser4 ?

[arodland]

I probably shouldn't write this here as I haven't yet found time to submit a decent bug report, but -- stay away from convertfs unless your drive has quite a bit of free space, or you don't care about your data. There is a bug in the way it uses 'mv' that means that it may eat your data in spectacular ways if it doesn't like your directory structure. It certainly did for me; I'm running on a system I reinstalled two days ago after my /boot and /etc got eaten, among other things.

Re:ext3 to reiser4 ?

[Omnifarious]

I wouldn't recommend crc32 for large volumes of data. Mostly because if you have any errors, they'll likely be more than single bit errors, and for a large enough amount of data will swamp crc32's ability to detect them.

I don't trust a hash algorithm that has collisions for anything, not even verification. Part of this is because I have a strong bent towards viewing things from a cryptographic standpoint, but another reason is this... If the algorithm is sitting around, there for people to use, it will be abused because people will not be aware that it is broken for certain purposes. It's better to get rid of it altogether.

For example, MD5 is now completely unsuitable for use as a verification mechanism for downloads. Removal of the tool from distributions makes it harder for people to abuse it for this use, and more likely that they'll use SHA-1, which does not have any proven attacks yet.

Re:ext3 to reiser4 ?

[Omnifarious]

Yes, but I can show you existing collisions for MD5. Can you show me any collisions for SHA1? One algorithm has been broken, and it's possible to generate collisions for it. One hasn't been yet.

Re:ext3 to reiser4 ?

[Nasarius]

reiserfs is used as the default filesystem in all of the examples).

Not quite all. The default (template) /etc/fstab uses xfs for the root filesystem.

Re:ext3 to reiser4 ?

[Omnifarious]

Nobody has demonstrated collisions for SHA-1 yet. Nobody has clearly demonstrated that they can generate collisions for the full SHA-1 in less than the 2^160 steps you'd expect it to take.

My point is that people should be discouraged from using algorithms that have been broken for their intended purpose. For example, MD5 can no longer be trusted as a method for verifying downloads. If it's available and its use encouraged, people think that it's good for verifying things. It will still be used for verifying download, and we'll all wake up one day to discover that gcc has been back-doored to put a back door in every ssh implementation out there and in itself.

Re:ext3 to reiser4 ?

[Omnifarious]

2^40 steps is how many it takes to break DES, and everybody thinks it's broken for that reason.

People should stop using MD5 as soon as possible. Algorithms that have been broken for their intended purpose should be abandon and their use discouraged, especially when there are perfectly good alternatives widely available.

Re:ext3 to reiser4 ?

[diamondsw]

Hold on a second - according to your own link, one CANNOT create a file that matches a given hash. They can create two streams with matching hashes, but they can't take an arbitrary existing file and create another file with the same hash.

An attacker can generate two messages M and M' such that Hash(M) = Hash(M'). Currently this is possible for MD5 but we have to consider the possibility that it will be eventually possible for SHA-1. Note that he cannot (currently) generate a message M such that Hash(M) is a given hash value, nor can he generate a message M' such that it hashes the same as a fixed message M.

Re:ext3 to reiser4 ?

[Wavicle]

Why is it important to find a collision if it is trivial to prove that collisions must exist?

Re:ext3 to reiser4 ?

[timeOday]

Well, that's simply the definition of "perfect hash," so yeah. But those are useless for verifying files.

Re:ext3 to reiser4 ?

[AvantLegion]

>> Statistically speaking you are more likely to get malaria in Arizona than experience a random MD5 collision.

I've been feeling ill ever since I came home from Flagstaff...

Re:ext3 to reiser4 ?

[Anonymous Coward]

I wouldn't be surprised to discover that the fact that you can generate collisions in the algorithm means that its distribution for random input is far from flat, and it's probably a bad idea to use it for anything.

No, the fact that you can generate collisions means that it is a hash algorithm. I can easily prove that SHA-1 has collisions, too, despite not having found any particular ones.

Re:ext3 to reiser4 ?

[1000StonedMonkeys]

I certainly don't disagree with you, but take a look at the original post. This discussion started off with talking about methods to verify that you'd succesfully copied your data from one partition to another. This is an application where security and the (supposed) presence of algorithms to generate collisions is completely irrelevant. The original poster just wants to make sure that the backup of his data isn't corrupted before he nukes it and reformats the partition with reiser4.

Re:ext3 to reiser4 ?

[Omnifarious]

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

Re:ext3 to reiser4 ?

[psetzer]

That requires that you find another program that has the same size as the first program, has the same hash as the first program, and does what you want while acting like the original program in every way other than that. Frankly, that's insane. While I don't doubt that such a program exists, finding it would be pretty much impossible, since there are 2 to the number of bits in the gcc file possible files of that size, and very, very few of them are valid gcc compilers. I'll be generous and assume that you've found one. Great. Too bad someone found some bug that only the truly depraved would ever think of (probably involving pointer arithmetic with function pointers), and oh, they made a new version with a different size and checksum.

Re:ext3 to reiser4 ?

[kasperd]

Nope convertfs won't work...
Why not? AFAIK the only two requirements for convertfs to work is that the original filesystem supports sparse files and the FIBMAP ioctl. Reiser3 have both these features. You must also have enough free disk space, and there will still be a risk of data loss in case of bugs in convertfs. So I wouldn't recommend using convertfs unless you actually understand it well enough to fix the filesystem if it breaks.

From the horses mouth
Written by who? If this is written by a person with no knowledge about convertfs (but maybe knowledge about reiserfs) how could he possible say if it works. The convertfs utility is designed to work with almost arbitrary filesystems. It doesn't contain filesystem code, it simply relies on the drivers in the kernel.

Re:ext3 to reiser4 ?

[Omnifarious]

It only takes me 2^40 operations to find another file that has the same hash. And I can find areas of the gcc compiler that it doesn't matter much if I change, like various parts of the documentation.

MD5 is broken. Stop using it.

Re:ext3 to reiser4 ?

[flux]

So? I've had a crash (with reiserfs 3.x), system boots up and reiserfs-root fails to mount, after reiserfsck the filesystem is empty. I shall declare this single datapoint proves reiserfs broken.

Infact that's not the only reiserfs-problem I've had - and not the only hardware I've had those on, of course the favorite excuse is broken hardware even though other filesystems have had no trouble - but I suppose it has become more robust later on. I also at some time had trouble with reiserfs and lvm, reiserfs filesystem appearing unrecognizable after boot even though the ReIsErFs-signature was found - this you may find from the mailing list archives too.

Later on most systems I've switched to ext3 and xfs. Atleast they have some history and they have a _working_ fsck instead of something that just rebuilds the tree, which may or may not bring back the fs.

Reiserfs is still suitable for me to use on data that needs to be accessed fast but isn't particularly important ;). Especially as a file name hash collision may bring unexpected trouble..

Re:ext3 to reiser4 ?

[Omnifarious]

But, I can show you particular collisions for MD5. Can you show me any particular collisions for SHA1?

Re:ext3 to reiser4 ?

[Emil Brink]

diff(1) is primarily a text comparison tool, it tries to find the minimum difference between two text files and is very handy for creating e.g. patches to source code. For comparing arbitrary files though, you might want a tool that simply compares them byte-by-byte, and in that case you need to use cmp(1).

Re:ext3 to reiser4 ?

[greg_barton]

Statistically speaking you are more likely to get malaria in Arizona than experience a random MD5 collision.

Actually, it's closer to the chance of getting malaria in Arizona while fucking Natalie Portman in a vat of hot grits electrified by a lightning strike.

Re:ext3 to reiser4 ?

[Anonymous Coward]

I've exactly the same experience here a year ago, reiserfs fails to mount, reiserfsck tells me to run it with --rebuild-tree, I do it and fails (segmentation fault): Bye bye filesystem, hello ext3!.

Re:ext3 to reiser4 ?

[Emil Brink]

Not in the current x86 Quick Installation, it doesn't. Scroll down a page or so for the /etc/fstab template, which suggests ext2 for the /boot partition, and reiserfs for the root. Hopefully they know what the recommend, so my recently-reinstalled laptop won't crash and burn. Heh.

Re:ext3 to reiser4 ?

[bigsteve@dstc]

But... if you are already in Arizona doing something unspeakable (which may or may not involve Natalie Portman, hot grits and/or lightning strikes) ... then the chance of getting malaria is higher than you probably realise!

Re:ext3 to reiser4 ?

[Jeremi]

People should stop using MD5 as soon as possible.

What bad things can or will happen if people keep using MD5?

Re:ext3 to reiser4 ?

[rjh]

Assuming you're not deliberately trying to break MD5, it requires 2**64 files to have 50/50 odds of creating one or more MD5 collisions. Check Google for the Birthday Paradox if you want a full explanation.

Re:ext3 to reiser4 ?

[Anonymous Coward]

I choose malaria, thank you very much for the rest.

Re:ext3 to reiser4 ?

[hansreiser]

XFS is better than ext3 for streaming large files and worse for "typical" file size distributions. XFS is more interesting than ext3 I think.

Re:ext3 to reiser4 ?

[RWerp]

Not over the past couple of years -- the original corruption problems with reiserfs, although pretty severe, are well in the past now.

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. This attitude should be applied to all new filesystems. I understand downloading a fresh build of mozilla, but I'd be more conservative with choosing a filesystem.

Re:ext3 to reiser4 ?

[Anonymous Coward]

My experience has been the reiserfsck generally does a less good job of recovering slightly borked filesystems than e2fsck. This is kind of what you'd expect, since ext2 gets borked far more often than Reiser, so it's fsck gets thoroughly tested,
and ext3 can then use almost the same code to recover if it has a problem.

Obviously, it isn't possible to make a fair comparison between the two, because they don't run on the same filesystems and the FS structures are
different enough that it doesn't make much sense to talk about ``similar levels of corruption''.

Having said that, the only reason I'm running ext3 now rather than reiser is that this machine dual boots with FreeBSD, which supports the ext family but not Reiser. Reiser is a seriously cool piece of code, but not yet perfect.

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 ?

[ArbitraryConstant]

Or just do what I do. Put all the stuff you care about on another computer with a time tested filesystem, and share it over the network. NFS is fast and has low latency. Not nearly as fast as a local drive (although you still want gigabit with good Intel NICs, you'll blow right past 100 megabit speeds), true, but fast enough for the things that typically reside in home directories. If necessary, files that must be fast can be stored on the local drive and rsync'd to the server regularly.

Then, you can switch filesystems and even OSes at the drop of a hat. You can blow away your entire hard drive and be up and running again in 20 minutes. The things that really benefit from a fast drive stay local and fast. The things that should be safe and easy to access and maintain stay on a server running OpenBSD or Debian-stable or something.

Another advantage is switching OSes. Linux has poor UFS support and no UFS2 support. FreeBSD has poor ext2 support, and you wouldn't want a partition that's supposed to be safe running that anyway. The only other common FS is vfat, which isn't even an option. With NFS, you can read it from anywhere (even MacOS X and Windows).

The one thing to consider is getting a UPS for the server. Async NFS mounts are much faster, but more vulnerable to power dropouts.

Re:ext3 to reiser4 ?

[FlashBuster3000]

Mhh, fsck tries to recover your fs if your computer stopped running, right?
Where's the point to this, when you have an atomic filesystem?

Re:ext3 to reiser4 ?

[zurab]

So? I've had a crash (with reiserfs 3.x), system boots up and reiserfs-root fails to mount, after reiserfsck the filesystem is empty. I shall declare this single datapoint proves reiserfs broken.

I don't know why you took what I said that way. Nobody's personal experience is a proof of a general theory of whether ReiserFS is "good" or "bad."

I don't know what version of ReiserFS/kernel/distro/etc. you were using, but you may get "bad" ReiserFS installations with distros that don't care about it too much and default to ext3 or something else. I've seen Hans trying to correct and give suggestions to some distros to be dismissed as arrogant or whatever else. This is, of course, no reason to conclude that ReiserFS does not work. For example, Mandrake, RedHat, and others do not pay close attention to properly configuring and patching for ReiserFS, so using those combinations "out of the box" may not be safe.

Later on most systems I've switched to ext3 and xfs. Atleast they have some history and they have a _working_ fsck instead of something that just rebuilds the tree, which may or may not bring back the fs.

I don't know about XFS and ext3, but ReiserFS does not require fsck. Again, I am not trying to prove a general theory, but the only times I have personally needed reiserfsck was when the HD was dying. And even then no data was lost.

Reiserfs is still suitable for me to use on data that needs to be accessed fast but isn't particularly important ;). Especially as a file name hash collision may bring unexpected trouble..

FUD!

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.

Re:ext3 to reiser4 ?

[datajack]

Doesn't matter, the fact is that there are collisions in MD-5, SHA-1 and any other hashing algorithm you care to mention. The 'goodness' of a hash is represented by howwell distributed results are among the hash-space. If you have 'clumps' of results, then you have a bad algorithm - I don't think that this hasd been demonstrated in MD5 yet.

Demonstrating a single collision, or a couple of manufactured collisions is not an issue. You can get worried if someone can produce a match for arbitrary data on request.

I should patent my own hash function that's guarranteed to not have any collisions - maybe that will make you feel safer? I've called it 'NULL', by the way ;)

Re:ext3 to reiser4 ?

[ASkGNet]

Except the fact that perfect hash does not support changing of dataset after performing the conversion to a perfect hash.

So please, take all possible files, run a perfect hash on them (remember, it will take at least O(N) and at worst - infinite amount of time), brew some coffee while you are at it, and you may want to steal a Cray or a thousand of them.

Also, by the Murphy's law, you will get busted by FBI in the last second before it completes running - since all the possible files include all the MPAA and RIAA-protected files.

(note, I am aware that the number of possible files is infinite - aleph 0 in fact - but let that slip for now)

Re:ext3 to reiser4 ?

[trentblase]

So you can find a garbage stream of bits that match the MD5 of gcc in 2^40 ops? So what? The chances of that bit stream being compilable let alone being exactly the same as gcc with "various parts of the documentation" changed are staggeringly low.

You are broken. Stop posting.

Re:ext3 to reiser4 ?

[beaubell]

LARt! LaRT! LArT!!!!!!!!! Where is my LART!!!!????!!!

Re:ext3 to reiser4 ?

[nikolas]

Reiserfs is a journalling filesystem in that it keeps your metadata and filesystem structure intact. Indeed, like any other journalling filesystem it does not journal your data. (with the exception of ext3 with the respective features tourned on). Reiserfs to my knowledge never tried to rescue data. Its simply something you have to know/remember.

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]

As far as I know the attack has not yet been published, so I'm kind of speculating here. What has been found is a method to generate collisions(ie this breaks collision resistance, but not 2nd-preimage resistance). It appears that the attack generates collisions for strings of 1024 bits by flipping 6 of the bits. Both strings are generated by the attack, so you don't get to choose them. You can choose text that you want to embed these strings in though. For example, suppose I have some data, and choose some point in the data. Given these preconditions, I can generate two strings of 1024 bits(differing in 6 positions) and insert these strings into my data at the specified position. This will result in two new pieces of data which have identical md5 hashes.

From my current understanding, the attack doesn't really help you at all if you want to do something like distribute modified(eg backdoored) versions of the Linux kernel.

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:ext3 to reiser4 ?

[ttldkns]

Alternatively use rsync's checksum feature! here are rsyncs best options to get an exact copy of your data: rsync -Ppogrtlhc *old location* *new loation* the options are permissions, progress, owners, groups, recursive, cant remember t, soft links, hard links, checksum. Not really for the overly paranoid but its always worked fine for me and i still have a functioning OS, just one with slightly better partitions!

Re:ext3 to reiser4 ?

[Anonymous Coward]

We didn't consider reiserfs.
...
We've lost data with both reiserfs and XFS.

Well, which is it? If you're going to spew FUD, at least make up your mind which story you're going to tell.

Re:ext3 to reiser4 ?

[Zork the Almighty]

From personal experience, Reiserfs is slow to mount large partitions, and slow to copy large files. Ext3 is much better in that regard.

Re:ext3 to reiser4 ?

[Anonymous Coward]

if it's there, people will keep on trying to use it for purposes for which it is no longer safe, like file downloads.

MD5 is still 100% safe for file downloads. The attacks recently published rely on the attacker being able to generate both versions of the file - and he doesn't get to choose either. The chances of one version being a useful program and the other being a virus are still essentially nil.

Re:ext3 to reiser4 ?

[Anonymous Coward]

Okay, here's your challenge: produce for me a version of GCC which has the exact same MD5 as an official release, and functions exactly the same as that release, but contains some form of malicious code. You can change as much of the documentation as you like to aid you in this task.

Until you have succeeded in this, kindly stop repeating "MD5 is broken" like a broken record. Don't worry about losing time, if you start right away I estimate you should just about be able to start trolling again before the heat death of the universe.

Re:ext3 to reiser4 ?

[Jesrad]

Humm, no, I'm pretty confident ROT-13 does not have collisions. The only problem is that hashes obtained with it are the same size as the fed data...

Re:ext3 to reiser4 ?

[bcmm]

A hashing system with no collisions is called "data compression". Take Gzip as an example...

Re:ext3 to reiser4 ?

[Anonymous Coward]

If you did combine rmd160, md5 and sha1 of 1 file as OpenBSD does with its Ports Collection then i think the possibility you play soccer with a meteor falling on your head is more likely than a collision in all 3.

Re:ext3 to reiser4 ?

[Anonymous Coward]

so far there haven't been any reports of corruption with Reiser4

"We have never had an undetected error"

Re:ext3 to reiser4 ?

[Bazzargh]

"In fact in his last set of tests when ext3 is setup to journal the same way reiserfs v3 did, ext3 soundly beats it except in the delete category."

I think you mean "ext3 is soundly beaten except in the delete category". In the mongo benchmarks:
http://www.namesys.com/benchmarks.htm l
You're talking about columnm, C "ext3 in data=writeback mode". Notice the note that says "Green number means that reiser4 loses in this test." Looking at the latest set of results, the real time column is RED except for delete.

No argument with your other points. I'd need to try reiser4 in the real world to be convinced the difference was worth it.

Re:ext3 to reiser4 ?

[chtephan]

That was because reiserfs only hat a writeback journal then. The means that it could happen (very often) that the metadata was written before the actual data was and you would end up with random data in the files that were written just before the crash.

I know it because I had the same problems.

But the current 2.6 kernels have a lot of improvements. reiserfs now also has data=ordered and data=journal journalling modes (with ordered-data being the default now). This means that the actual data is written before the metadata is committed. I've never had those problems again.

And, BTW, it's hardly the fault of the filesystem that you lose some data if your system crashes.

The current reiserfs in 2.6 also has a lot of other improvements. A better block allocator, quota and ACL support. If you need those for 2.4, SUSE has had the patches in their kernels for some time now.

Re:ext3 to reiser4 ?

[Anonymous Coward]

dude use lvm

Re:ext3 to reiser4 ?

[Anonymous Coward]

Like the hundreds of posts where Americans are pissing and moaning that companies are outsourcing jobs away from their lazy asses to a country like India who doesn't demand more for less like Joe "I'm an American, The world revolves around me, Let's teach those Johnny Iraqi's a lesson" Sixpack.

Re:ext3 to reiser4 ?

[CanadianCrackPot]

Ahh the fools, just get a second hard drive and backup data to it. I'd use Reiser across all my drives if I still didn't play some games in Winblows 98, or needed access to files I made in OOo... very rare that I do though.

Re:ext3 to reiser4 ?

[Filik]

Is there any filesystem out there that can perform fsck while mounted and in use? For production environments, it is really bad to have to be down for 6 hours while filechecking, even if it is only done every 6th month. Also, if the host only boots once a year, most linux variants wont ever force a filecheck.

-Filik

Re:ext3 to reiser4 ?

[TheRaven64]

Making a hashing algorithm with no collisions is easy. Here's one:

void * hash(void * data)
{
return data;
}

Re:ext3 to reiser4 ?

[Anonymous Coward]

I agree with everything you said. Also, XFS is fast because it take priority in the kernel. This means applications get less CPU (ie. it's not good for desktop machines).

Once they added ordered data mode to ReiserFS (v3) it became very reliable also.

That brings up another point. Our choices of filesystem were extremely limited because we wanted a journaling filesystem that journaled the data not just the meta-data. That left us with only two choices: ext3 and reiserfs (v3).

On my desktop machine I have a few firewire drives. Since the sbp module tends to be flaky (especially with fsck) I needed something that doesn't ever need to be fsck'd. That left me with reiserfs. With ordered data mode it has had a perfect track record.

Re:ext3 to reiser4 ?

[Anonymous Coward]

And you don't have a UPS?

Who doesn't have a UPS? They like come in the power strips nowadays.

Re:ext3 to reiser4 ?

[Anonymous Coward]

Funny?? Do you slashdotters ever read comp.compression and sci.crypt?
This is the pigeonhole argument in just about the purest form there is. It's true and it's relevant here. Whether it's easy to purposefully manufacture them is irrelevant since no-one is attacking here so it boils down to two things: Does it work as an ordinary hash and is your file count anywhere near 2**128?

Re:ext3 to reiser4 ?

[Anonymous Coward]

It still takes like 2^51 or 2^80 operations to brute force any of these little nuggets though.

Nit: if you can find a collision in a hash with an expected operation count that's less than a square root of the number of possible hashes, it's not bruteforcing. I'm not sure if I'd call even birthday attack brute force.

Re:ext3 to reiser4 ?

[Anonymous Coward]

Ok, let me see if I understand you correctly: nVidia closed source drivers crash your machine, go take a shit on kernel memory, play games with kernel stack, etc, behind your back and God knows what else (since it's closed source and we can't know what the hell it is doing, anyway), and this is Reiser's fault how, exactly?

This wasn't nVidia drivers prior to being 4K stack compliant, by any chance? I've seen ext3 going south in screams, also, because of that.

The moral of sthe story is, nVidia's binary only drivers are a huge pile of crap. Not nVidia itself, that has been very helpful lately, providing documentation and open source code for some of their products (ethernet chips, ide chips, agpgart stuff), but their 3rd-party-IP-infested-and-therefore-unopenable GPU drivers.

Re:ext3 to reiser4 ?

[swillden]

Whenever a file would be created on that mount point that exceeded 4G,... We never had a problem like that was the ext's

No, you had a different problem... namely that the ext2 and ext3 file systems don't support files that big.

Re:ext3 to reiser4 ?

[MemoryDragon]

Well ext3 has another advantage, although I prefer Reiserfs (being a mostly java developer I love the performance on thousands of small files). The main problem ReiserFS has is that there is no decent read/write way from windows, which makes it on dual boot machines (face it those are the most common machines) a pain. For ext3 you have the explorer like program to export and import data, and a commercial driver. For reiser, there is nothing non commercial or commerical, I would love to pay a small amount of money for a good reiserfs driver for windows. And I am sure lots of people would (here me namesys?)

Re:ext3 to reiser4 ?

[bit01]

Early versions were flaky as hell and had obviously never been tested on an actual corrupt file system, nor coded with all possible file system failures in mind. Core dumps, exceptions, you name it.

Whoever wrote it didn't know what they were doing. Newer versions are probably better but once burned, twice shy. I don't trust people who code file system checking utilities as an afterthought.

---

It's wrong that an intellectual property creator should not be rewarded for their work.
It's equally wrong that an IP creator should be rewarded too many times for the one piece of work, for exactly the same reasons.
Reform IP law and stop the M$/RIAA abuse.

Re:ext3 to reiser4 ?

[Luyseyal]

Interestingly, Phoenix is now home to mosquitoes and West Nile virus due to a bunch of old stagnant swimming pools. Heard it on the radio.

-l

Re:ext3 to reiser4 ?

[FooBarWidget]

Yes, I agree. While ReiserFS is faster than ext3, I choose ext3 because it doesn't leave junk behind in my files when my system crashes. ReiserFS 3 couldn't do that. It protects the metadata, but not the data.

With ReiserFS 4 that has changed, so I will seriously consider ReiserFS next time I format my harddisk.

Re:ext3 to reiser4 ?

[Anonymous Coward]

Or, rather, gentoo provides an out-of-the-box functioning fsck for ext3 while it doesn't provide one for reiserfs.

I don't get it either.

Re:ext3 to reiser4 ?

[Moloch666]

I see you've gotten may replies, but I'll add a me too. I don't think this has happened since I've started using the 2.6.x kernel. Almost 80% of the time my system hard locked,,all open files, whether being written to or read from (config files, etc) would be hosed. Very bad... I'm still using reiserfs v3, but now it is ROCK solid. Especially with the write barriers kernel patch.

For example, I've had issues with athcool locking my system. Finally recently decided to troubleshoot. In about a week's period I experienced about 50 hard locks. Tracked down the problem, turned out to be BIOS settings. My system is perfectly stable never lost any data.

Re:ext3 to reiser4 ?

[irf]

Statistically speaking you are more likely to get malaria in Arizona than experience a random MD5 collision.

it's not the random collisions that we worry about,
it's rather the engineered ones which take advantage
of weaknesses in the hash algorithms to achieve
their goals that we should worry about.
there is no such thing as a collision free hash
algorithm, for the simple reason that the domain of
the input is infinitely larger than the domain
of the output, that is, the output of the hash function.
current advances indicate that all MD based
hash algorithms are susceptible to attack.
it is only a matter of time before all MDx based
hash algorithms will be literally broken by refinements
of the current attacks.

Re:ext3 to reiser4 ?

[menegator]

There is a big difference. All 1024 bytes long files have a 16 bytes MD5 hash value. Not every file has the same size after compression.

Re:ext3 to reiser4 ?

[tuffy]

For comparing arbitrary files though, you might want a tool that simply compares them byte-by-byte, and in that case you need to use cmp(1).

The problem with cmp is that it only works for a single file. If one wants to compare all the files across two different directory trees (like /home and /mnt/home_backup) diff's recursive option is very handy. Add the -q option (which reports only whether the files are different, not the differences themselves) and diff is a fine method of verifying local backups - such as an rsync'ed USB drive.

Re:ext3 to reiser4 ?

[Fweeky]

"I don't know about XFS and ext3, but ReiserFS does not require fsck"

Duh; no filesystem *needs* fsck if you don't mind fixing it yourself with a hex editor when it breaks. Hardware failure, filesystem bugs, and entropy are all virtually guaranteed to hit you sooner or later, and then you're going to *really* want a good well tested and mature fsck tool.

"FUD!"

Yup; Fear, Uncertainty and Doubt are the three most important things when it comes to evaluating new filesystems, especially ones with a recent history of data loss, broken fsck, and moronic vendors. ext2/3 must be pretty bad to make you lot want to switch so badly :/

Re:ext3 to reiser4 ?

[Aardpig]

Like what? Stop trolling arsehole. Please point to a significant amount of racist posts, or shut the hell up.

Ah, good to see that the BNP is here!

Re:ext3 to reiser4 ?

[Khazunga]

Incidentally, the Handbook is very pro-ReiserFS (although it also says ext3 is "an excellent filesystem," reiserfs is used as the default filesystem in all of the examples). If you spend time on the Gentoo Forums, you will find a number of people who claimed reiserfs tried to kill their computer, and an equal number who swear by it.

It wasn't always like that. When I installed my laptop (eer, ~2yrs ago) they aggresively recommended XFS, stating that reiserfs was unstable. I was very used to reiser (my previous distro was SuSE), but I remember the docs scared me into using XFS. Bad bad decision. On power outages, XFS would null-pad any files that were open for writing at the time. Real real bad. Lasted a month before I reformated with reiser.

Heh, I realize now: Two years without reinstalling the PC is quite a landmark. Go Gentoo...

Re:ext3 to reiser4 ?

[Anonymous Coward]

Hi there.

I have the full set of 29,642,774,844,752,946,028,434,172,162,224,104,410 ,437,116,074,403,984,394,101,141,506,025,761,187,8 23,616 unique 33 byte files, one of which is "There's gold in them thar hills!". I can tell you that, from that set, there are roughly 256 files with the same MD5 hash.

The original poster was stating that he has found a collision and can show you it. This isn't statistically unlikely. He's not saying he'll find a collision for an arbitrary MD5 hash of your choice. Don't be such a smug twat.

Re:ext3 to reiser4 ?

[TheAcousticMotrbiker]

OK, so this will be considerd just anecdotical evidence (and rightfully so, because it is), but I've recently encountered a reiserfs corruption issue (on a laptop, that ran out of power)

And I've still had problems with reiser over NFS
(there used to be the case that is you had a file/dir with test in it's name it would be seen as a dir if it was a file and v.v.)

Also, the recent mantel kernels from Suse had an issue with reiser hash clashes where creating a file with a 2-letter name caused the creation of a ghost file with a similar name.

The biggest benefit I see for ext3 is that if ext3 gets confused/corrupted, you can tunefs it back to ext2, and then run the tries and tested and rocksolid ext2 recovery tools to recover them.

Having said all that, reiser4 looks extremely good and promising, and Im more then happy that many people start using it, so that they can be bit by the bugs, and that when it's fully stable, I can safely switch as well ;)

Re:ext3 to reiser4 ?

[Aardpig]

it's not the random collisions that we worry about, it's rather the engineered ones which take advantage of weaknesses in the hash algorithms to achieve their goals that we should worry about.

Go back and read why I advocated md5sum in the first place. This thread is nothing to do with cryptography or security, it's about checking that the temporary backup of data to a remote server avoided random corruption. There is no real scope here for engineered collisions.

Re:ext3 to reiser4 ?

[drinkypoo]

Actually, it's closer to the chance of getting malaria in Arizona while fucking Natalie Portman in a vat of hot grits electrified by a lightning strike.

...in Japan.

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:ext3 to reiser4 ?

[Hatta]

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

Better advice. Use rsync. This is what it was made for. It will recursively compress and checksum an entire tree, preserving links and permissions. A very flexible tool.

Re:ext3 to reiser4 ?

[shaka]

Heh, I realize now: Two years without reinstalling the PC is quite a landmark. Go Gentoo...

Two years? I've been running the same installation of Debian for four years on 4-5 different computers at three different jobs. Just switching disks and kernels from time to time.

I always find it amusing when people talk about reinstalling systems (or even "upgrading" by doing a new install!), 'cause it's been so long since I last had to install an OS.

Re:ext3 to reiser4 ?

[a3217055]

Why does this happen I have noticed it, this is a journaling FS ( ext3). Ext3 was derived from SGI's XFS. I have seen this many times on ext3 and it reads the journal and yet it still after a year of usual server usage it goes out of sync and needs an fsck. What is going on ? thanks take care -A0

Re:ext3 to reiser4 ?

[antiMStroll]

Thanks for the explanation, but my nature when it comes to pain and trouble of a Stage 2 Gentoo build is once (or in this case repeatedly) bitten twice shy, especially with at least two alternatives proven to run solidly for me. The XFS soft-RAID stripe on my server has seen power go down many times without incident, that reiserfs install corrupted system files every lockup. Maybe ReiserFS 5 or 6. Or 7. ;)

Re:ext3 to reiser4 ?

[irf]

@Aardpig,
i hope that your remarks are not racially motivated,
as your signature seems to indicate, however, MD5 is a bad choice of hash algorithm for the purpose that
you indicate.
hth

Re:ext3 to reiser4 ?

[Aardpig]

i hope that your remarks are not racially motivated, as your signature seems to indicate,

My sig is nothing to do with this discussion, it is a general comment on an uglier side of Slashdot. Too bad that you've taken offense at it, but I'm not going to alter it for your sake. If you think it is specifically targetted at you, get over it; I neither know nor care about your race, creed, color or ethnicity. And don't forget that, likewise, you know nothing of me -- so ease up with your assumptions, boyo.

MD5 is a bad choice of hash algorithm for the purpose that you indicate.

Would you care to back this up with an argument, or am I supposed to just swallow it on your fiat?

Re:ext3 to reiser4 ?

[gid]

I had to use reiserfsck about 2 years ago to repair a somehow corrupted reiserfs3 partition. The hardest part was finding a bootdisk with reiserfs and reiserfsck so I could fix my main partition. After that, it was an easy fix, no important files missing.

With all my machines and servers running reiserfs, that was the only time it has failed me.

Re:ext3 to reiser4 ?

[irf]

@Aardpig,
how about crc32??
if you want a higher degree of confidence, and security, how about TIGER, or the SHA-2??
and i still, find your sig repugnant, and if you really care about what you
are trying to convey, i think you ought to change it.
my 0c

Re:ext3 to reiser4 ?

[Q2Serpent]

Bzzt. Too bad "hashing algorithms" go from a large domain to a fixed range (i.e. the result range non-infinite), or there's no point in hashing at all...

Re:ext3 to reiser4 ?

[Q2Serpent]

Possibly. I've never used it, but convertfs sounds promising.

Re:ext3 to reiser4 ?

[snol]

Dual-booting might not be done for the main Linux demographic (servers), but it's a big deal for desktop users to be able to dual boot and at least read all their partitions under all OSes. For this reason I use ext3 and, unfortunately, fat32 for storage partitions. I don't care so much about the performance of fat32 but I definitely miss having per-file user/group/world permissions on those filesystems when I'm in linux. I would love to see more advanced filesystems that are read-write under linux and windows both. There are ok ext2 drivers for Windows but I don't know that they're stable enough for write access, plus they don't support journaling.

Re:ext3 to reiser4 ?

[Omnifarious]

No, I am extremely concerned that people at large will continue to think that MD5 is fine when it's not. Why use MD5 when everybody who has MD5 has SHA1, which is fine?

Re:ext3 to reiser4 ?

[Omnifarious]

I can't easily, with tools I have handy, produce an MD5 collision for that statement. I do not believe the current state of things would allow the creation of such a tool that could run in a reasonable length of time.

I do know that I can (pretty easily) give you two files which have the same hash. I could prepend both of those files to that statement, and I would get the same hash for both files, though they are different.

MD5 is broken for some purposes. When a crytographic algorithm is broken for the purposes it was originally designed for, people should stop using it. Partly because a chink in the armor may be exploited in unexpected ways in the future. And partly because people will keep on using it for purposes it doesn't work for if people who know better don't tell them that it's broken.

Cryptography is subtle, and if an algorithm has known flaws, it's hard to know when you're doing something that will trip across one. Hash algorithms are supposed to have a certain set of well-understood properties. MD5 no longer has them. It can still be used securely for some purposes, but each purpose requries a lot of careful thought to decide if the algorithm's flaws will make it vulnerable in that situation. It's best to just get everybody to stop using it altogether.

Re:ext3 to reiser4 ?

[WhiteDragon]

my biggest beef with XFS and JFS is that they don't have any shrink capability. Ext2 and reiser can be resized in both directions, growing and shrinking. XFS can be resized, but only to grow. The strange thing is that while ext2/3 must be resized offline (not mounted), reiserfs (3, I don't know about 4) can be grown online, but has to be umounted to shrink, and xfs *has* to be mounted to resize! I don't know about growing JFS though.

Re:ext3 to reiser4 ?

[Omnifarious]

Even the ability to manufacture collisions is bad.

Since I'm tired of writing essentially the same thing over and over again, here's a link as to why.

Re:ext3 to reiser4 ?

[NoMercy]

I expierenced many problems with XFS, most notably files would shrink to 0 bytes in size every now and again when the system crashed without closing files, which for a journaliing filesystem I'm sure isn't supposed to happen.

ReiserFS 3 has been my stable FS since then, and I've not had any troubles, far faster than XFS for dealing with small files to boot, admitidly I do miss the ease of playing with files of over 500Mb as quickly as XFS, but for stability I'm happy with my move.

Someone also mentioned bad block handling, personally I'd rather see some form of data recovery built into the OS, at least so I can pull of as much data as possible, even a 1/2 complete file is better than nothing when recovering a system from HD failure.

Re:ext3 to reiser4 ?

[ePhil_One]

you can actually set this so that it won't ever fsck itself without you doing it. Just so you know :)

Yes, and to its credit it informs you how to do this after you perform a mkfs.ext3. But its something that has to be done, its not the default behavior; and it might catch quite a few novice admins unaware, especially if they are working with remote systems they did not build.

Re:ext3 to reiser4 ?

[k98sven]

Ah, a typical example of straining gnats and swallowing camels..

MD5 is perfectly safe for file downloads. The chance of someone generating a file with an identical hash which is in any way useful is practically zero.

On the other hand, the chance of your webserver being hacked and the hashes changed is HUGE by comparison. And that risk is just as big for SHA1.

Get some perspective!

Re:ext3 to reiser4 ?

[phoenix_rizzen]

The problem with reiserfsck is that is will halt a boot of a RedHat system (waiting for someone to type "Yes" or "No" to run the fsck), that it is not named the same as the rest of the fsck tools (you can't use "fsck -t reiserfs"), and the output is completely different from the rest of the fsck tools.

Why can't all the filesystem designers rename, or provide links on install, their fs utils to match the standard fs utils??

Re:ext3 to reiser4 ?

[JohnFluxx]

Hmm, I don't really follow.

I'm guessing that you are refering to that the BNP say that aren't racist, they just don't want non-whites in the the uk, etc.

Do you feel that my post is saying that there aren't racist posts, just that americans/english deserve the jobs more?

Re:ext3 to reiser4 ?

[Anonymous Coward]

You're asking for a second-order preimage, not a collision.

Re:ext3 to reiser4 ?

[Anonymous Coward]

Oops, forgot about the birthday problem. You meant 2^64.

Re:ext3 to reiser4 ?

[Anonymous Coward]

Nope, I was about to plot that number there, but there's no birthday problem here. We're just checking whether the file is changed, not trying to check which of them it is.

Re:ext3 to reiser4 ?

[RWerp]

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

Because it did not enter wide-spread usage as yet. Did anybody carried out some sort of stress test of the filesystem?

Re:ext3 to reiser4 ?

[Heywood Jablonski]

Suppose you've got a 1K file. There are 2^1K possible values that file can assume.

2^8K possible values, unless you meant a 1Kbit file.

Re:ext3 to reiser4 ?

[zurab]

Duh; no filesystem *needs* fsck if you don't mind fixing it yourself with a hex editor when it breaks.

If ReiserFS "breaks" it replays the affected transactions, it does not need to fsck. If your drive is bad, or your installation broken, then it's unsafe with *any* filesystem, not just ReiserFS.

Yup; Fear, Uncertainty and Doubt are the three most important things when it comes to evaluating new filesystems, especially ones with a recent history of data loss, broken fsck, and moronic vendors.

No, but FUD is one thing to keep in mind when reading posts like these, talking about some "history" and facts and things like that.

ext2/3 must be pretty bad to make you lot want to switch so badly :/

I don't "want to" switch. I did that few years ago.

Re:ext3 to reiser4 ?

[motyl]

That rsync options may be summed as "-a" option.
I usually use "-av"

Re:ext3 to reiser4 ?

[Wavicle]

I am not convinced that it is broken for the purposes it was designed for. At the absolute most, all that has been shown is that there may have been found an algorithm which can, when given one data set, find a second, very slightly different, data set with the same hash. This opens up the possibility of a denial of service type attack, in that an attacker could muddy the waters out there with a seemingly identical, but corrupt, image of another file. I'm sure the RIAA and the MPAA are salivating over this discovery.

Nothing known allows an attacker in a reasonable amount of time to insert a malicious payload into a file, even if it were as simple a change as altering text in a coherent way, while keeping the same md5 hash. If you download a file which both passes md5 and properly unzips, you can at this time be confident that no error or attack has occurred.

Re:ext3 to reiser4 ?

[tuba_dude]

For security purposes, of course avoiding old algorithms makes sense. This is just file integrity checking, just making sure everything survived the copy operation. I don't know the exact value, but the possibility of a corrupted copy having the same MD5 hash as the original file due to an error (hardware, software, user, whatever) is probably low enough that MD5 hashing can still be used for this purpose.

Re:ext3 to reiser4 ?

[Fweeky]

If ReiserFS "breaks" it replays the affected transactions, it does not need to fsck. If your drive is bad, or your installation broken, then it's unsafe with *any* filesystem, not just ReiserFS.

Right; disk and RAID controllers screw up, cables fail, memory goes bad, power failures mess up out of order and track at once writes, and all sorts of other issues can cause a filesystem to break in ways a journal cannot protect you from -- that's the entire point; it's all well and good being able to replay a journal and have it work fine 9 times out of 10, but when things go wrong I'd rather be using something mature with good, proven recovery tools than the latest and greatest just-released filesystem.

Whatever; you can have your few percentage points better performance, and I can have my quarter of a century of use and development, and we'll both try to remember to keep backups of anything important either way ;)

Re:ext3 to reiser4 ?

[zurab]

Right; disk and RAID controllers screw up, cables fail, memory goes bad, power failures mess up out of order and track at once writes, and all sorts of other issues can cause a filesystem to break in ways a journal cannot protect you from -- that's the entire point;

I see what you are saying but journaling does protect you from most of these. You are saying what happens in cases where it doesn't. In that case, at least in my experience, reiserfsck has worked several times on a dying HD. But don't take this as a general theory, for all I know you are right and ext2 fsck is better at what it does.

it's all well and good being able to replay a journal and have it work fine 9 times out of 10

FUD.

when things go wrong I'd rather be using something mature with good, proven recovery tools than the latest and greatest just-released filesystem.

mp3.com (when it was at its peak), half of SourceForge.net, and many others do not agree with this your statement. ReiserFS is mature. You could argue this with Reiser4.

Whatever; you can have your few percentage points better performance, and I can have my quarter of a century of use and development, and we'll both try to remember to keep backups of anything important either way ;)

Agreed.

Re:ext3 to reiser4 ?

[Fallen_Knight]

"There's gold in them thar hills!" = 32 bytes ?

Re:ext3 to reiser4 ?

[Dwonis]

*I* have a UPS, but I also have *backups*, which means I don't have much need to convert an existing filesystem to a new format. I suspect that most people who want to convert to a new filesystem want it because they don't have backups. I also suspect that there is a strong correlation between people who don't have backups and people who don't have UPSs. Thus, my post.

Re:ext3 to reiser4 ?

[Dwonis]

Why the hell did that get modded "Funny"? I don't get it.

Oh, I must be new here.

Re:ext3 to reiser4 ?

[Omnifarious]

I think people should toss it out anyway. It doesn't matter that it can be OK for some things and not others. What matters is that it no longer satisfies the requirements for a secure hash function. This means, that for some set of purposes you'd use a secure hash function, it's no longer good.

This means, every time you think about using MD5, you have to decide if it's secure for that purpose or not. And that will sometimes not be a very easy question. It's best just to scrap the entire thing, and quit using it completely than to try to educate everybody about all the things it is and isn't good for now.

*sigh* I should've thought things through carefully before I posted and made my remarks much more careful and bounded. But, I still think my main point is valid.

Re:ext3 to reiser4 ?

[Omnifarious]

You can use the vulnerability also to try to probe the internal details of a protocol implementation to attempt to learn keys and things. Several OpenSSL vulnerabilities have been based on timing attacks on error handling. If you can generate two payloads that have the same hash, you can get past a level of verification, and possibly learn something from how long it takes the system to reject your packet.

Also, you can prefix two identical packets with different sets of chosen garbage bytes and have them hash the same. It's also possible (though I'm not at all sure) that you could insert the different sequences of bytes into the middle of two otherwise identical packets, or suffix those packets with them, and still have them hash the same. Any of these may open up interesting vulnerabilities in various protocols.

I base this conclusion (and subsequent speculation) on knowing that MD5 and SHA1 are vulnerable to length extension attacks because the internal state of the algorithm is easily determined from the final value. So, you can just backtrack from the final value to the internal state that generated it, then start adding bytes.

I don't really understand the mathemtics behind the problem they've found with MD5, but it seems to me like it might open up the possibility of being able to manufacture one sequence that has the same hash as another sequence that you have no control over. And if that can be done, MD5 isn't safe for practically anything people use MD5 for currently.

I just don't like seeing algorithms that have proven problems being encouraged for use. There's a lot of misunderstanding of cryptography out there. I would rather people treat algorithm breakage with unreasonable paranoia rather than having them try to find the set of things it's still good for. Especially when there are replacement algorithms that are just as widespread, and have not yet been broken.

Re:ext3 to reiser4 ?

[aka1nas]

So for you those of you that have experience with all these filesystems, which would be the best for storing "vast" amounts of multimedia files? Coming from the windows side, NTFS sucks once you start getting something like 100 to 200GB of video files on one partition. Would reiserFS on a linux box fare much better for that type of application?

Re:ext3 to reiser4 ?

[minion]

Whenever a file would be created on that mount point that exceeded 4G,... We never had a problem like that was the ext's

No, you had a different problem... namely that the ext2 and ext3 file systems don't support files that big


I'd love to give you access to my server so you can login and see for yourself that ext3 does support files greater than 4G. Infact, MOST of our servers store very large data sets in single files, some upwards of 500G without fault.

No, my reference was that XFS had problems when creating a file bigger than 4G. Please read my rant before you rant back, and check you facts.

Re:ext3 to reiser4 ?

[Anonymous Coward]

Is there any filesystem out there that can perform fsck while mounted and in use?

This would be really bad, since you have the potential for collisions; while fsck is making a correction, another process writes its data into the inode/filestructure, then fsck comes along and overwrites this change with the old, corrected data. boom, like that, data is lost.

Re:ext3 to reiser4 ?

[minion]

We didn't consider reiserfs.
...

We've lost data with both reiserfs and XFS.

Well, which is it? If you're going to spew FUD, at least make up your mind which story you're going to tell.

I'm sorry, I'm mixing my timeline with my story.
Our current barrage of tests didn't include reiserfs for consideration because we had lost data in the past on reiserfs v3.

To me, having to restore a critical server from tape because of a fs glitch is reason to ditch that fs. The hardware it was on, it is still going strong on, now with ext3.

Re:ext3 to reiser4 ?

[WindBourne]

with these FS, it is not so much the size of the partition (all the journalling do terabytes just fine), but the average size of the files. XFS screams on the large files that are used at Hollywood and in genetic labs (10-1000's of gigs on a single file). If you are dealing with smaller files (most less than 100 meg), reiserfs or even jfs should shine. It is the inbetween that becomes a toss up.

Quite honestly, I use reiserfs3 on my home system (one of my systems is .5 terabyte used for holding our family data), while at work we have Fedora Core 1 with Ext3 and XFS partition. If you have important work, you may wish to use XFS or reiserfs 3 until reiserfs 4 has geled for a while. If you have data that is backed-up or easily regenerated, then reiser4 is an interesting choice.

Re:ext3 to reiser4 ?

[Anonymous Coward]

You almost got it right, why did you have to throw in the non-infinite bs? Pointers have a fixed range, given it will almost always be larger than the fixed range but it is definitely fixed.

Re:ext3 to reiser4 ?

[Anonymous Coward]

CRC32 is NOT safe to use for file verification. Have you ever had the experience of downloading a file (via FTP perhaps) and then it turns out the download was corrupted? Deleting the file and downloding a second time fixed such problems (almost) every time, right?

There are CRC checks in both the IP and TCP protocols. CRC and CRC32 are NOT cryptographically secure, nor are they single-bit error safe.

With MD5 (and other true hash algorithms) every single bit in the input is reflected in every single bit in the output. The lack of this property in CRC is why it is not safe to use for file integrity verification.

MD5 question -- if you limit the input length of your messages (arbitrarily) then the likelihood of finding two arbitrary messages that hash to the same value becomes much less (for ANY hash algorithm). What makes a cryptographically-secure hash algorithm "cryptographically secure", is that we can work without such arbitrary limits and still, the likelihood of finding a message M' that hashes to the same value as M is so small, as to not be feasable. This should not be limited to only those possible values for M' that are "sensible" but should work for nonsense values, as well.

Re:ext3 to reiser4 ?

[gordyf]

ROT-13 is not a hashing algorithm.

Re:ext3 to reiser4 ?

[tpeland]

>As far as reiserfs is conserned, bring me quota and i'll consider it.

It has been in the standard kernel starting with 2.6.7. I have been using it in production servers (one of them has 20 000 users) for about two months now. I suggest you give it a try.

Windows port?

[Anonymous Coward]

Will we ever have a Windows port of ResierFS or any alternative filesystems?

Re:Windows port?

[Coneasfast]

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

Re:Windows port?

[Aardpig]

Will we ever have a Windows port of ResierFS or any alternative filesystems?

I'm not sure about ReiserFS, but there is already a program -- Explore2fs -- which lets you mess around with Ext2 and Ext3 partitions from Windows. Why you would want to do that is beyond me, but there you go.

Of course, you may be talking about a native Windows implementation of Ext2/3 and/or ReiserFS. Which is a totally different kettle of fish...

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?).

Re:Windows port?

[Daverd]

I'm not sure about ReiserFS, but there is already a program -- Explore2fs -- which lets you mess around with Ext2 and Ext3 partitions from Windows. Why you would want to do that is beyond me, but there you go.

I have a hard drive with Windows installed on it and a hard drive with Linux, and I use both OSes. Explore2fs is handy when I'm in Windows but I need to grab a file on my Linux drive.

Re:Windows port?

[Aardpig]

I have a hard drive with Windows installed on it and a hard drive with Linux, and I use both OSes. Explore2fs is handy when I'm in Windows but I need to grab a file on my Linux drive.

I usually make sure the file is in a FAT partition (yes, I know, eugh!) which both OS's can see. Not as convenient as your approach, but I don't want to give any opportunities for some piece of Windows malware to download itself and then trash the data in my Linux partitions.

Re:Windows port?

[j3110]

YAReg

http://yareg.akucom.de/index.html

works for me now.... I have to say I would much prefer a real driver, but beggers can't be choosers.

Re:Windows port?

[base3]

A dot NET filesystem driver? I feel dirty.

Re:Windows port?

[Anonymous Coward]

"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?"

Are you on crack or do you just not know that NT has always been about modular units. Cripes you have a monolithic kernel + modules kludge compared to a micro kernel. This idiocy/ignorance of basic comp sci hurts my head. Sorry. NTFS.sys and some loaders handle low level NTFS there is also a FAT/FAT32 driver and an NFS (thirdparty) filesystem driver. Back in the day even some Linux projects have used these files to mount NTFS partitions under Linux. Quit your idle Windows bashing knee jerk reactions. They just show how little you know about much of the computer landscape.

I myself would not be surprised if Reiser4 makes it to Microsoft's neck of the OS woods. Heck knows that that the NAMESYS webpage implies that they have made covert ports of past filesystems for other vendors and Microsoft has buckets of cash. Heck the processes are also well documented maybe even better documented than under Linux. To head off the knee jerk reaction of the few OS zealots that often piss on rational exposition here, yes you can sign an NDA and see just the file system hooks used by for instance Windows XP and get a nice binder documenting EVERYTHING you need to put your filesystem under Windows. So no there is nothing technically breaking a port and infact it might even be easier than writing a Linux module because the underlying OS of Windows NT has not changed as much as many believe.

Sorry to burst your bubble but not only is it possible but I think Namesys as a company should consider it. Heck I personally would pay for a better file system under NT/2K/XP/2K5. My employer would pay even more and MS heck the skies the limit. You would be either a fool or a zealot to not consider the deal. Afterall Linux could use Reiser5 and developement could always use a shot in the arm financially. If only to pay for pizza and beer ;-)

ping

Re:Windows port?

[Black Acid]

I'm on a laptop, where hard disk space is relatively scarce, and I use Explore2fs to access my music collecton stored in my /home. Its very useful. Creating a separate partition cause problems if the data in one of the partitions grows unexpectedly.

I can't speak for rfstool as I haven't tried it (just found out about it today--otherwise I'd be using ReiserFS), but Explore2fs doesn't create a virtual drive, therefore other programs cannot (as far as I know) access the files. Of course, malware could write to the disk directly, but it could do the same to a FAT partition.

Re:Windows port?

[DarkEdgeX]

I believe this is what you were looking for--

IFS Kit - Installable File System Kit

Re:Windows port?

[j3110]

It's just for the GUI :)

Don't you have a shiney new GMail account and use GTray already? GTray is a .Net app.

Maybe it works with Mono, but I doubt it because I think it uses windows forms, and we all know that Mono doesn't really support that so well yet.

I don't hold it against them because there really is no point in running a ReiserFS browser on more than one platform. :)

Re:Windows port?

[itzdandy]

try this, run bochs with a small linux distro, no gui just bash. install samba to have access to ALL linux compatible filesystems and export you /mnt folder via samba.

this would also allow you to 'map a network drive' and give your samba share a drive letter.

Re:Windows port?

[say]

There is a way (a kit, actually) to develop "Installable Filesystems" for Windows. However, this kit costs real money, and noone seems to think it is important enough to do this.

There has been a few attempts to develop a native ext2 filesystem driver for Windows, but it didn't work/was extremely unstable.

Filesystem support is not, AFAIK, in kernel32.dll, but in some other .dll. So, it is "insertable" into the kernel, like kernel modules (only less secure and stable).

Re:Windows port?

[irc.goatse.cx troll]

Explore2fs is nice, but if you want something better, take a look at ext2fsd. You can actually mount the partition(eg, G:\ or whatever) and have all your data usable by any windows app, rather than having to navigate inside explore2fs and copy it out.

It can read/write ext2 and readonly ext3, and hasnt messed my data up yet. if you're scared leave it in its default readonly mode and you should be fine.

google will find a link, its also linked to at the official ext2fs homepage on sourceforge.

Re:Windows port?

[Donny Smith]

>So, it is "insertable" into the kernel, like kernel modules (only less secure and stable).

Less secure? Errh, how so? If "insmod fs" (the Windows equivalent) is controlled by the system and the file system supports standard ACLs, why would it be "less secure"?

If it is less stable, how come there are ISVs that create scalable cluster file systems* for Windows using this kit?

* I am talking about file systems for Windows here (unrelated to extx or ReiserFS on Windows)

Re:Windows port?

[Lonewolf666]

Sorry to burst your bubble but not only is it possible but I think Namesys as a company should consider it. Heck I personally would pay for a better file system under NT/2K/XP/2K5. My employer would pay even more and MS heck the skies the limit.
Might be a good idea IF they hold all of the copyrights. Reiser FS is open source, so it is possible that others outside of Namesys have contributed as well.

Re:Windows port?

[base3]

I saw that it was just the GUI after I posted. Of course, I think the .net framework has as much long term chance as the UCSD p-System and the JVM that came before it. Heck, .net doesn't even have the advantage of being (designed to be) cross-platform. Mono is a sop to hold off Justice, nothing more.

Re:Windows port?

[Chutzpah]

That depends on demand, if someone is willing to pay Namesys to port reiserfs to windows, then yes there will be reiserfs for windows, but that is unlikley to happen since it will cost at least in the 5 digits, probably 6. I personally don't see much of a need, windows people can stick with NTFS, which is a passable filesystem.

Namesys are the only people that can legally actually do a port of teh existing code, they own the copyright, and they can relicense it. Since it is GPL'ed it would be likley be illegal to release a port that links into the non-GPL windows kernel.

If someone were so inclined they could re-implement reiserfs on windows, but that would be IMHO a massive project.

oooooo, dancing trees!

[fishbert42]

... but can they tango?

Re:oooooo, dancing trees!

[peculiarmethod]

"* Reiser4 uses dancing trees, which obsolete the balanced tree algorithms used in databases (see farther down)"

that's what he meant.

oh, and whoever moderated offtopic didnt rtfa, either. damn, peeps.. what is wrong with this community these days?

pm

Re:oooooo, dancing trees!

[Jeremi]

I don't know about you, but for me the tfa isn't about algorithms at all, but rather is a very short piece regarding "server timeouts". :^P

Re:oooooo, dancing trees!

[Fortyseven]

Not just trees, but ATOMIC DANCING TREES. Crazy shit, and obviously representing a superior filesystem. :D

Re:oooooo, dancing trees!

[fishbert42]

Bah! Security through obscurity, I say!

Re:oooooo, dancing trees!

[evvk]

But the real question is... can they headbang?

Re:oooooo, dancing trees!

[zby]

I don't know about tango, but samba was mentioned in the article.

Re:oooooo, dancing trees!

[Anonymous Coward]

that's what he meant.

Well, duh. But if that's the entire reason for his "joke," and it wasn't also some clever reference to something, then he is a moron.

That's what I meant.

I can see the headlines on Slate...

[Anonymous Coward]

ANOTHER linux server has been taken to its knees by an organization of users presumably using, yes, linux.

Only one question...

[Pathway]

I only have one question (And I obviously have not researched an answer...):

Is there an easy and non-destructive way for me to migrate my ReiserFS version 3 to a version 4 Filesystem?

--Pathway

Re:Only one question...

[EMN13]

Well, Mr. Reiser Dude suggests tar in his posting to lkml which can also be viewed on kerneltrap.org.

In other words,

no.

Re:Only one question...

[Anonymous Coward]

Problem: GNU tar doesn't back up ACLs or Extended Attributes.

Re:Only one question...

[jrcamp]

Star does though.

Re:Only one question...

[asdfghjklqwertyuiop]

Problem: GNU tar doesn't back up ACLs or Extended Attributes.

Presumably the reiserfs dump utility should take care of that. I don't know anything about reiser, but XFS's dump takes care of the ACLs and everything else.

Re:Only one question...

[codemachine]

Too bad ReiserFS doesn't have a dump utility.

Re:Only one question...

[pnatural]

And the answer is cheap! You should view the namesys.com support page:

$25 gets you an answer to a question about anything.

BTW, I'd like to know the answer, too. Could you go pay and ask the question, then come back and tell us all the answer?

Re:Only one question...

[Anonymous Coward]

Given the statement from that posting :

A statement on compatibility with reiserfs3 filesytems.

To upgrade from reiserfs V3 to V4, use tar, or sponsor us to write a convertfs.

Then this is probably one good reason never to run ReiserFS

I know I dont want to have to rebuild my server (because I chose ReiserFS (v3)) for some of the file systems.

Until the conversion needs little or no interaction from me (and is trusted), I doubt I will be using ReiserFS v4.

Re:Only one question...

[Zork the Almighty]

It's more or less a totally different filesystem. Get over it.

Re:Only one question...

[bogado]

Can I get my money back? I think I will question about the meaning of life.

Re:Only one question...

[bogado]

Damn hurry, I should have done a preview... :-P It should read:

Can I get my money back, if the answer is not stisfatory? I think I will question about the meaning of life.

Re:Only one question...

[kasperd]

Until the conversion needs little or no interaction from me (and is trusted)

A filesystem conversion utility needs a lot of testing before you can really trust it. IMHO it just isn't worth the effort. It will probably take less work to just use tar or cp -a than to test the conversion. And even if somebody said they had carefully tested the conversion utility, would you trust that they hadn't missed some litle bug that happens to show up on just your system?

There does exist a filesystem independend conversion utility. It relies on features in the standard kernel. It simply moves all files into a new filesystem on a sparse loopback mount, and then maps the loopback filesystem back on the original partition. The maping back is the most complicated part, and since I wouldn't trust such a utility unless I understood the code, I have never used it. Besides the script wrapping around the whole thing was a bit flawed, so I would do that part by hand if I needed to.

ATOMIC FILE-ING SYSTEM HERE I COME

[Icyfire0573]

Just a quick hop skip and a jump from Reiser3 to reiser4 i hope,
Faster all around, modular & with atomic commits so you don't lose stuff in case of a power loss!!!

Re:ATOMIC FILE-ING SYSTEM HERE I COME

[dekeji]

Faster all around, modular & with atomic commits so you don't lose stuff in case of a power loss!!!

It's not that simple. Support for atomic operations in the file system eliminates a few sources of catastrophic data loss and it enables applications to avoid some other sources of data loss. But you will still lose unsaved data, you may still lose file system changes that haven't been committed, and, unless applications are changed, you will still end up with partially written files if the power fails while an application saves its data.

Re:ATOMIC FILE-ING SYSTEM HERE I COME

[ctr2sprt]

I'm sorry, but when you're talking about hard drives, there is no "atomic." It's as simple as a power failure while the disk drive is in the middle of writing a block (albeit a block sent atomically by the OS). Or as simple as a RAID controller with a write cache, or a hard drive with a write cache. Or hell, you could lose power while bits are flying across the controller cables.

And yeah, you'd better believe it happens. The BSDs use a similar approach called SoftUpdates (basically odrered writes). If power craps out in the middle of a write, you will have corruption. The main advantage is that, because writes aren't scattered all over, you only lose the file(s) you were most recently working on. This focuses the damage, it doesn't reduce it at all.

Re:ATOMIC FILE-ING SYSTEM HERE I COME

[Geiger581]

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.

Re:ATOMIC FILE-ING SYSTEM HERE I COME

[ceswiedler]

The point isn't to guarantee that data was flushed to disk. But if it wasn't, you know it wasn't, and you have a previous copy of all the blocks in the transaction.

Atomicity isn't the same thing as synchronous writes, where the OS won't return from the write() call until the data has truly been flushed successfully to the disk controller (and with controllers which support it, to the platter itself). Atomicity says that a set of writes either happens completely, or not at all.

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:ATOMIC FILE-ING SYSTEM HERE I COME

[dtfinch]

Or at least that's how it's supposed to work. If you're not careful, there are a lot of things that can break that atomicity, like hard disk write caching without battery backup or write order preservation. You'll still be protected in the event of a crash, but a power loss can be just as destructive as ever.

And if you want the advertised speed, you'll probably have to accept the default of meta-data journaling only. Though I can't double check to be sure, since namesys is slashdotted, your options with just about every journaling file system is either meta-data journaling (default) or full journaling (slow). Ext3 provides a good balance between the two modes which is the default.

Re:ATOMIC FILE-ING SYSTEM HERE I COME

[Anonymous Coward]

Nope. You can achieve atomicity with disk write barriers, write-back cache and all.

Re:ATOMIC FILE-ING SYSTEM HERE I COME

[itzdandy]

you don't understand atomic writes.

file A exsist here /data/fileA.txt
you move file A to /otherplace/

filesystem copies fileA.txt to /otherplace/, verifies that the copy has completed, and THEN deletes original.

you see, when it verifies the filesystem, it checks to make sure that the data is their. it doesn't just trust that the harddrive has written it to disk, it waits til the write command has returned a positive.

also, you don't understand a hard drives cach correctly either. unless data is being read at the exact moment of the write, ZERO data will be cached for later writes, the cache is primarily for READING data as many reads are not alligned near each other on the dist, so the cache reads the entire block into cache before it seeks to a new sector so that the next read from the first track is in cache. hard drive caches are for reads primarily and writes only occasionally. also, some OS and filesystems will not do a simultanious write and read to avoid such situations(this is legacy behavior, from when drives barely had any cache).

Re:ATOMIC FILE-ING SYSTEM HERE I COME

[hansreiser]

No, atomic is the only option for reiser4, there is no metadata journaling even as an option. So, it both goes faster and keeps your data safer. It is nice when experiments with algorithms work.... :)

Hans

Re:ATOMIC FILE-ING SYSTEM HERE I COME

[hansreiser]

No, actually, waiting before deleting the old copy is not enough. You need to make sure that there are not two copies.

Think of classic banking example: credit savings and debit checking are a single atomic operation. You must ensure that you don't get the credit preserved and the debit lost by a crash.

The poster above you was right.

Re:ATOMIC FILE-ING SYSTEM HERE I COME

[Daniel Phillips]

I'm sorry, but when you're talking about hard drives, there is no "atomic." It's as simple as a power failure while the disk drive is in the middle of writing a block (albeit a block sent atomically by the OS).

Think again. Either "dancing trees" or traditional journalling can checksum the commit block of the transaction, so that if it's only partly written to disk the final transaction isn't committed. If your disk hardware is so broken that it could trash a sector that's not being written, you need to switch vendors.

And anyway, typical modern disks don't even trash the last few sectors in flight, there's enough power coming in through the drive motor from the mechanical energy of the platter to get the sectors actually under the write heads safely onto the medium.

Re:ATOMIC FILE-ING SYSTEM HERE I COME

[nikster]

let's assume you have an atomic FS where all the data you write doesn't matter as long as the nodes are not updated, or, more abstractly, as long as confirmation of this transaction has not been written.

the advantage is then that writing the confirmation is much faster and the likelihood of the writing of the confirmation being interrupted by a power outage much lower.

assuming that, the worst case would be that power goes out _during_ the writing of the confirmation.

so a truly atomic FS needs to be able to deal with partial confirmations.

this is pretty tricky to get right as you have to prove that for every possible confirmation this system will work, e.g. no checksum collisions etc.. you have to prove that for all possible confirmations C containing N bits, you can handle the case that 0, 1, 2, ... N-1 bits have found their way to the disk.
for example, the system could feature a final confirmation confirmation which consists of just one bit. before the transaction takes place, that bit is set to 0, and after the transaction is finished, it is set to 1. data loss due to power outage can still occur in such a system, but file system corruption can't.

if reiser4 truly can do this, it's pretty damn cool and i will be pretty impressed. it's a sign of maturing software where critical operations don't rely on the old "crossing my fingers and hoping for the best" way of doing things.

Re:ATOMIC FILE-ING SYSTEM HERE I COME

[Anonymous Coward]

Hmm. You raise a very interesting point, and one I am not, sadly, competent to discuss. Your last paragraph is by far the most interesting part of your post to me. I don't doubt you at all, because I do not think I have ever seen circumstances to be considered contradictory; and in my current job I oversee several thousand heavily-(ab)used servers, I would think that if such examples were common, I would have.

Simply for my own edification, and hence the anonymous posting - this is ctr2sprt - would you care to elaborate on the mechanisms used to ensure that this sort of thing doesn't seem to happen? Again, I am not doubtful because, as I said, my experience backs up your statement. I just have an overly inquisitive mind, perhaps.

Re:ATOMIC FILE-ING SYSTEM HERE I COME

[Daniel Phillips]

"Simply for my own edification, and hence the anonymous posting - this is ctr2sprt - would you care to elaborate on the mechanisms used to ensure that this sort of thing doesn't seem to happen?"

Admittedly, this is largely a matter of lore since one seldom runs into a Seagate or IBM disk engineer, and when one does, one seldom gets strong drink into her to reveal the arcana of disk drive internals. However:

http://www.cs.princeton.edu/~rywang/berkeley/pap er s/idisk/idisk/node8.html#SECTION000320000000000000 00

"Modern disk drives use residual power to park their heads in a landing zone at the outer perimeter of the disks prior to spinning down the drives."

If you've got time to park the heads, you've certainly got time to complete writing the current sector in progress, which only takes a few tens of microseconds even on slow disks. Does the residual power come from the spinning platter, or capcitors, or does it come from the PC power supply? Good question, I'm speculating above. If you turn up some hard data, post it somewhere please. :-)

Reiser4 may be great....

[moosesocks]

but will it save Namesys from a slashdotting?

Seriously.... their server admins must be FSCKing angry.

Re:Reiser4 may be great....

[dtfinch]

That's what happens to web sites that stuff all their information and graphics into 3 monolithic pages.

Re:Reiser4 may be great....

[Feztaa]

And pretty much any other page that gets linked to from slashdot.

Re:Reiser4 may be great....

[hansreiser]

We only have a 100 megabit fiber optic connection to the internet, and it can't handle this load, sigh.... Slashdot is amazing....

Hans

Various filesystem compared

[a-z0-9]

The latest issue of Linux Format has an article on the various filesystems. Have not read it yet though.

Been using Reiser4 on the / for 2 weeks now

[Anonymous Coward]

Yea, I would definitely recommend it. It's extremely speedy.

XFS

[Anonymous Coward]

Where are the benchmarks comparing it to XFS?

Helpful Mirror

[Anonymous Coward]

Reasons why Reiser4 is great for you:

* Reiser4 is the fastest filesystem, and here are the benchmarks.
* Reiser4 is an atomic filesystem, which means that your filesystem operations either entirely occur, or they entirely don't, and they don't corrupt due to half occuring. We do this without significant performance losses, because we invented algorithms to do it without copying the data twice.
* Reiser4 uses dancing trees, which obsolete the balanced tree algorithms used in databases (see farther down). This makes Reiser4 more space efficient than other filesystems because we squish small files together rather than wasting space due to block alignment like they do. It also means that Reiser4 scales better than any other filesystem. Do you want a million files in a directory, and want to create them fast? No problem.
* Reiser4 is based on plugins, which means that it will attract many outside contributors, and you'll be able to upgrade to their innovations without reformatting your disk. If you like to code, you'll really like plugins....
* Reiser4 is architected for military grade security. You'll find it is easy to audit the code, and that assertions guard the entrance to every function.

V3 of reiserfs is used as the default filesystem for SuSE, Lindows, FTOSX and Gentoo. We don't touch the V3 code except to fix a bug, and as a result we don't get bug reports for the current mainstream kernel version. It shipped before the other journaling filesystems for Linux, and is the most stable of them as a result of having been out the longest. We must caution that just as Linux 2.6 is not yet as stable as Linux 2.4, it will also be some substantial time before V4 is as stable as V3.

Re:Helpful Mirror

[Anonymous Coward]

Novell's NSS that they are porting to Linux is supposed to blow away reiserfs

Re:Helpful Mirror

[dubl-u]

Sure, the text might be helpful, but I think much of the value of this article comes from the images that go with it. E.g., this one.

No, really, they use a bunch of illustrations like this in the linked article. It dumbfounds me.

Re:Helpful Mirror

[Anonymous Coward]

Do you want a million files in a directory, and want to create them fast? No problem.

Reiser3 sure has a problem with that. I took 40 about minutes to create 125,000 0-byte files before I killed the test. Is Reiser4 that much more efficient?

root@localhost:/tmp/reiser-no-problem> uname -a
Linux foobar 2.6.5-7.104-default #1 Wed Jul 28 16:42:13 UTC 2004 i686 athlon i386 GNU/Linux
root@localhost:/tmp/reiser-no-problem&g t; mount |grep " / "
/dev/hdf6 on / type reiserfs (rw,acl,user_xattr)
root@localhost:/tmp/reiser-no -problem> date;for i in `seq -w 1 1000000`; do touch $i; done;date
Tue Aug 24 00:12:25 EDT 2004
^C
root@localhost:/tmp/reiser-no-problem&gt ; date
Tue Aug 24 00:51:23 EDT 2004
root@localhost:/tmp/reiser-no-problem> ls|wc -l
124266

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:Helpful Mirror

[JamesKPolk]

Plus, for filesystems, there *is* a definition: Mandatory Access Controls are a published NIST standard.

Re:Helpful Mirror

[tonyr60]

" Reasons why Reiser4 is great for you:

* Reiser4 is the fastest filesystem, and here are the benchmarks."

All the benchmarks show is that Reiser4 is a bit faster than EXT3. No mention of Sun's new fs (ZFS) or any other. I don't see how it can justifiably called the fastest file system.

Re:Helpful Mirror

[Anonymous Coward]

Novell's NSS that they are porting to Linux is supposed to blow away reiserfs

Fascinating, but completely off-topic, tending towards flamebait.

The ReiserFS that NSS "blows away" is Reiser3, the current mainstream ResierFS. This article is about Reiser4, a complete ground-up rewrite based on totally different technology - which also blows away Reiser3. Along with everything else NameSys are admitting having benchmarked it against.

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:Helpful Mirror

[greenrd]

I don't think ZFS is officially released yet, so how could they ethically benchmark it?

Re:Helpful Mirror

[Anonymous Coward]

because we invented algorithms

They invented an algorithm? Is that like discovering the value of pi or inventing the value of pi?

Re:Helpful Mirror

[swillden]

There is no standard of "military grade security" by which such claims can be measured.

How about this definition: Meets the security requirements given to the developers by the military.

Re:Helpful Mirror

[Anonymous Coward]

As a person who has worked in what you can call military industry and done service, I can tell you the term "military grade security" mans something so big an cumbersome that people would not steal it :-)

Re:Helpful Mirror

[bobv-pillars-net]

What Hans won't point out is that Reiser is less forgiving of bad hardware than Ext2/3. This is why you hear conflicting reports of reliability. The negative reports are from people who don't invest in reliable hardware and backups; the postive ones are from people who do.

Reiserfs has a much more complex data format than Ext3, and v4 is more complex than v3. This means that the reiser fsck program has to work a *lot* harder to repair data corruption than the ext2 fsck. Even so, the latest version can handle just about anything except for unreadable/unwritable sectors.

So for cheap hardware, use the cheap (Ext2/3) filesystem, but for quality hardware, use Reiser4.

Re:Helpful Mirror

[Blackknight]

Actually, yes, there is a standard.

Check out the rainbow series of books. Any operating system or software used by the military must go through a security certification process.

Windows NT is certified at C level security. Some of the features needed for military security are ACL and MACs on the file system level.

I know everyone's thinking it...

[Elote]

IT'S ABOUT FREAKING TIME!!!!!

I did an informal comparisson of this fs against several others for one of my classes, and my results had it winning _hands down_.

But on a more serious note, I hope this release is stable. From lurking on their mailing list, it seems that it hasn't been too long since they were in bug-squashing mode.

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

[Anonymous Coward]

What class was that for? Because I think I may have been in it. We had someone do one of their presentations on the ReiserFS 4 and ever since then I couldn't wait for it to come out

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

[Anonymous Coward]

If you would have read the artice you would have seen this.

"We must caution that just as Linux 2.6 is not yet as stable as Linux 2.4, it will also be some substantial time before V4 is as stable as V3."

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

[Elote]

Nope, this was a "research paper" for my operating systems class, never presented it to the class except for bragging on the results.

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:I know everyone's thinking it...

[SLi]

I agree. I did such an informal test myself some time ago, and reiser4 won easily (but lost my test data at least back then - I'll wait for a while before trying it again).

See this comment for the raw data from the test.

Who's got the balls...

[Stevyn]

...to use it for a while. I'm sure it's been tested very extensively, but there are always bugs initially in any major release like this. I'm sure nobody running a server will touch this for a while even with the benchmarks.

I'm not trying to spread FUD on reiser at all, I run reiser 3 and I've never had any problems. I'm just raising the question of how long does it take until people will put it in production servers and their main desktops?

Anyone who maintains servers care to shed some light on this?

Re:Who's got the balls...

[ianster]

I might put it on some testing servers immediately and see how it goes. Production use would follow 3 - 6 months after that, depending on how many bugs are found and versions released until then. I run a pretty small shop of 30 servers, and I'm probably closer to the bleeding edge than most larger companies.

Re:Who's got the balls...

[Anonymous Coward]

I'd definitly start running it on testing servers and see how it goes, but I'd probably wait a year or so for production depending on how it goes.

Re:Who's got the balls...

[dtfinch]

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:

http://www.redhat.com/archives/fedora-list/2004-Ju ly/msg00418.html

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.

Re:Who's got the balls...

[vandan]

Yep.

As I just posted, I've been running it on a number of desktops here at work with no issues.

It ROCKS!

Re:Who's got the balls...

[SaDan]

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.

Re:Who's got the balls...

[uhoreg]

That's old news. That particular case of ReiserFS corruption is due to the fact that ReiserFS (until a little while ago) only did metadata jounalling and did not ensure that data is written before metadata. The problem could have been fixed by applying a well-known patch (at least well-known among the ReiserFS community), which has recently been merged into the mainline kernel (at least the 2.6 series, though I'm sure 2.4 has it too).

Reiser4 does not have such a problem, as it operates in data=ordered mode by default.

Re:Who's got the balls...

[adoarns]

Tengo cojones grandes.

Seriously, been feeling the love of Love sources for over a week now, with 60GB of reiser4 goodness.

Mind you, you have to take what the love-sources guys say seriously, about renicing the filesystem process to prevent it from bogging down under load -- but that was all prerelease stuff. Plus, as much as I b0rk that box, the constant rebooting while still mounted can't even dent the fs.

Fantastic.

Re:Who's got the balls...

[Chilling_Silence]

Why are all server admins today so bloody stupid! Have you never heard of UPS! Either that or run a laptop as a server if you're that worried about power outages! It should never be a concern... You want performance and stability, not worries about power outages! You have a problem (Power outages) so fix it! (UPS)

Re:Who's got the balls...

[Anonymous Coward]

I realize this doesn't help much, but I switched to Reiser a year ago. And one night, the power went out, and when I booted up the next morning, the Reiser FS was toast. The version of Reiser that I was using was a supposedly very stable 3-series version (on a machine whose hardware worked -- and still is working -- perfectly).

I have since used XFS on an experimental basis (on a newer, different machine), and have twice lost the drive. No big deal there, but it strikes me that XFS is still very experimental.

I finally stabilized on JFS. I have been running it for ~8-10 months on the 12 machines that I manage at work (and also including two at my home), and have found it to be fast and very stable. (Our machines have several-month uptime.)

I will continue to hold off on switching to Reiser until, one day, after zillions of people have run it and have extoled its "greatness", I *may* switch. (All things aside, I highly doubt that my switching from JFS to Reiser will make any perceptible difference in the performance that I see. But, time will tell.)

Re:Who's got the balls...

[SaDan]

I don't worry about power outages, not with the two weeks of battery power I have at the end of my building, and the 1500 gallons of diesel for the generator just outside the building.

I do have to worry about fucking CPU fans that decide to fail, or crappy workmanship that results in a loose cable, reusing hardware that should have been at the wrong end of a shooting range three years ago, etc.

And even when the hardware doesn't fail, extreme loads on a box tend to make it unravel every once in a while.

That's why I use and recommend ReiserFS. It's saved me more than once, and saved the company more than twice.

Re:Who's got the balls...

[timmarhy]

you obviously aren't a sys admin. UPS is not protection against your systems power failing, just against it losing mains power. what if a gecko crawls into your PSU and blows it? what if your mobo packs it in? all these = power failure.

Re:Who's got the balls...

[The_Dougster]

I'm just raising the question of how long does it take until people will put it in production servers and their main desktops?

Personally, I currently use Debian as my main desktop system for most things, but I have a semi-experimental Gentoo partition which I am tinkering around with as a sideline. I'll probably wipe Gentoo and start with a clean Stage1 install on Reiser4 next time I work on it. I can do this because I install Gentoo from a chrooted environment from inside Debian with a kernel that has Reiser4 support already built in.

Re:Who's got the balls...

[asdfghjklqwertyuiop]

I have since used XFS on an experimental basis (on a newer, different machine), and have twice lost the drive. No big deal there, but it strikes me that XFS is still very experimental.

When was this? What version of the kernel? I've been using XFS just about everywhere I can for years now and I have never lost a filesystem by software problems.

IMO XFS is the most stable filesystem linux has. It has the most mature and complete set of tools and features, has good and consistent performance and is very stable. Like JFS, it is not new. It was ported from another operating system and has been around for a long time now.

Re:Who's got the balls...

[mindstrm]

And during that one moment when, say, your UPS fails, or the plug gets kicked out of the back of the computer, or some moron leans on the power switch too long...

Or when your power supplies fail....

The list goes on...... other hardware failure, fire, earthquake... etc.

Do you want a system designed to not corrupt itself to hell and back during a hard outage, or not?

Re:Who's got the balls...

[Pathway]

When is it stable?

When Debian Stable has it as an installable option. Reiser 3 is now an installable OS, but it hasn't been in there that long.

Seriously, though... I plan on giving it a shot when it appears in Debian Testing, and then after I prove it's working on a non-critical box, then I'll think about moving it over to production machines.

Re:Who's got the balls...

[Chilling_Silence]

Motherboard failure, that's unpreventable Everything else... Why would somebody be leaning on the power button on a server? Surely you keep a server away safe so that sorta thing doesnt happen! Ive been using it personally on my own home http/ftp/samba/jabber servers, not to mention on a few other servers Ive setup. None have had a power failure in the last 3 months so everybody's happy!

Re:Who's got the balls...

[amorsen]

In the test, the filesystem eventually failed to mount, and reiserfsck failed to fix it. Not very nice at all. Some lost data is one thing, a lost filesystem is quite another.

Re:Who's got the balls...

[hansreiser]

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

Re:Who's got the balls...

[Anonymous Coward]

Motherboard failure, that's unpreventable Everything else... Why would somebody be leaning on the power button on a server? Surely you keep a server away safe so that sorta thing doesnt happen!

You've never worked as a professional sysadmin have you?

Ive been using it personally on my own home http/ftp/samba/jabber servers..

That answers my question.

Re:Who's got the balls...

[Zork the Almighty]

I'll probably put it on my main desktop in a few weeks. Granted, it won't be doing anything right away, I'll just try it out and see how it works. If it works well, I'll try using it for my portage tree (Gentoo). Depending on how much I like it, I might try it using it in other places.

BTW, what is the deal with ReiserFS being dog-slow for copying large files ? It's also dog-slow mounting larger partitions (ie: 80gb). I've tried tweaking everything to no avail. Now I just use Ext3.

Re:Who's got the balls...

[deathguppie]

I tried Reiser4 about 10 months ago. I had to build a kernel that supported it on one hard drive and then migrate to a second Reiser4 hard drive to use it. The result was unfortunately that during a system crash I lost data and the system was unrecoverable. So was the hard drive. But I still feel that it was noticibly faster.

Re:Who's got the balls...

[mattgorle]

Our company's fileserver will continue to use ReiserFS 3 until there's a good enough reason to upgrade it. For me, this would be something like replacing the server through hardware failure. At the moment, it just works. It's only accessible from the inside of our network, doesn't see much of a load, and the software has shown itself to be stable enough for me to almost forget that it's there.

Basically the bottom line is that Reiser 4 may be the best thing since sliced bread, but until I need to update the software on that machine, it's not going to be updated. After all, if it ain't broke...

Re:Who's got the balls...

[Ed Avis]

If reiser4 operates in data=ordered by default and the benchmarks are taken in that mode, then it's very impressive. I believe that ext3 for example takes a big performance hit (for many applications) with data=ordered.

I like the idea of data=ordered because of its 'no lies' property - if the kernel says the bytes have been written to the file, they have been - and if reiser4 can support that while keeping reasonable performance it would be good to switch.

Re:Who's got the balls...

[Ed Avis]

Hmm I think I was confusing data=ordered and data=journal... never mind.

Re:Who's got the balls...

[Anonymous Coward]

I have tried XFS with 2.6.5, and earlier, with a patched 2.4.9 (or so) kernel. The latter was during XFS's early development, so the loss of the filesystem didn't surprise me. The former was on an install that I made just a few months ago -- and it did surprise me to lose the FS.

Re:Who's got the balls...

[Anonymous Coward]

That sounds like dirty pool.

Re:Who's got the balls...

[Anonymous Coward]

LOL Hans you're not only a great developer, but you're also funny as hell!

cheers!

Re:Who's got the balls...

[Oestergaard]

Well, several of the ext3 people are employed by RedHat - it makes sense that they don't want to work with Reiser but rather spend time on ext3.

As a company, when you have good employees who like to do A and don't want to do B, you can either force them to do B and deal with the possible consequences, or simply prioritize B lower and be happy with A.

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

And no, I don't mean to bash RedHat - no distributor is big enough to do everything 100%.

Re:Who's got the balls...

[Anonymous Coward]

And no, I don't mean to bash RedHat - no distributor is big enough to do everything 100%.

Except Debian. ;-)

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:Who's got the balls...

[Oestergaard]

You mean, the distro that ships a 2.2 kernel by default, a broken 2.4 as an option, and has a package management system that leaves half-installed packages around when it encounters errors?

No, I don't think they are big enough either.

(yes, I use Debian on everything I have that is important - because they're the best, and the significant downsides are either acceptable or can be worked around - but they're not perfect either).

Re:Who's got the balls...

[Gojira Shipi-Taro]

Agreed. That describes my experience with ReiserFS twice (both times I used it). I've never had that kind of corruption with Ext3. I've lost some data, rarely, but I've never had an issue with eventually repairing the FS.

When I have an FS to repair, and the provided tools segfault when presented with the job before them, a warning flag does tend to go up :/

Re:Who's got the balls...

[asdfghjklqwertyuiop]

Is that 2.6.5 you had problems with a SuSE kernel?

Re:Who's got the balls...

[Anonymous Coward]

Hasn

Gesundheit.

Re:Who's got the balls...

[moon-monster]

I've been using it for my root partition on my main desktop, and my laptop for a bit over a month. I do however use reiser3 partitions for /home as I don't want to lose any code.

Having said that, I haven't lost any data, or experienced any crashes... And it makes portage a lot snappier too.

Two more questions....

[macdaddy]

What does it take to patch NFS and quota tools to support Reiser...

...and what if any Linux distributions support it out of the box?

KARMA WHORE!!!!

[Anonymous Coward]

Look at the post above this one by an AC. It's the exact same thing! This guy ripped it off.

Re:KARMA WHORE!!!!

[Anonymous Coward]

It was only minutes apart. It seems that they both submitted very close to each other.

What's with that link?

[Chordonblue]

There doesn't seem to be a Windows version of Reiser on that li....

Oh...

Re:What's with that link?

[WindBourne]

No, there is a windows version of it. Let me, or one of my friends, e-mail it to you. It will arrive as a pif or a .exe. Just double click it inside of outlook.

Yea that homepage looks like alot of others

[TigerTime]

"The Namesys homepage in its current stage is reminds me of a cross between The Secret Guide to Computers and the GNU Manifesto " Yea, i see "This page cannot be found" on alot of websites

Re:Yea that homepage looks like alot of others

[HoppQ]

"The Namesys homepage in its current stage is reminds me of a cross between The Secret Guide to Computers and the GNU Manifesto " Yea, i see "This page cannot be found" on alot of websites

Well, duh, it's supposed to be a cross between "The Secret Guide to Computers" and the GNU Manifesto, how secret would it be if you could actually find it?

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?

Re:Stability

[Wesley Felter]

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

Re:Stability

[Anonymous Coward]

Not even this much?

Re:Stability

[hansreiser]

Our response is definitely not so what. We might have told you that metadata journaling (what V3 uses) provides a level of service in which, like FFS and many other filesystems before it, if you crash during a write the write gets garbled.

Reiser4 is fully atomic though, and a write will either make it to disk entirely or not at all, with no data garbling. In other words, assuming that metadata journaling was what made you unhappy, we listened, but waited until a deep rewrite could allow us to fix it with no significant performance loss.

We are very happy that the use of wandering logs allowed us to make things atomic without losing any significant performance.

Re:Stability

[Anonymous Coward]

Dancing trees, wandering logs - sounds like the ReiserFS development lab is more of an anthropomorphic lumbermill.

Can reiser4 withstand the slashdot effect?

[Anonymous Coward]

www.namesys.com is responding pretty slowly already.

Is that due to a bottleneck in the filesystem under heavy load? Hope they're running reiser4 :-)

His thoughts on NTFS...

[blackketter]

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....

Re:His thoughts on NTFS...

[Anonymous Coward]

Hmm.. Reiser poopooing reliablity features? Say it aint so...

Re:His thoughts on NTFS...

[irgu]

The "Inside the Windows NT File System" book is 10 years old and discusses an at least 14-15 years old design. However over the last 10 years, apparently Microsoft worked hard on NTFS because it was improved a lot performance (pre-fetching data, metadata rearrangements, block allocation optimizations, etc), features (sparse file, compression, encryption, quota, symlinks support, etc) and reliablility-wise.

NTFS was usually between Reiserfs and Reiser4 in the benchmarks I've seen so far. Reiser4 being always the fastest by about 5-20%.

Regarding their homepage's looks,

[Anonymous Coward]

They don't care,
they don't have to,
they are the "ReiserFS" company!!!

Well?

[iamdrscience]

Somebody post a bulleted list of featuress already! I'm a busy man, I don't have time to read anything longer than two and a half pages of double-spaced 12pt Courier, and that's only for the executive summary of my encyclopedia A-L anyways.

Re:here is the text from namesys.com

[Tyir]

Actually, v3 is NOT the default filesystem of Gentoo, Gentoo has no default filesystem, you pick what you want. They give the easy option of ext2/3 xfs and reiser

Sweet!

[chizu]

Now when will we see it in the vanilla kernel?

Re:Sweet!

[hansreiser]

If we go for a week in -mm with no bug reports, I send it to Linus.

Re:Sweet!

[Anonymous Coward]

Good luck! (seriously)

Re:Sweet!

[Erik Hensema]

Which is useless, since Linus only accepts patches from Andrew.

Re:Sweet!

[fadir]

Doubt that, at least AC told something different the last time I saw him on a conference ... ;)

First Post

[HermanAB]

Damn ext3...

Comment removed

[account_deleted]

Comment removed based on user account deletion

No compelling reason to upgrade

[Anonymous Coward]

I'm going to stick w/ Emacs for my filesystem thank you.

Re:No compelling reason to upgrade

[Anonymous Coward]

You mean the "My Computer" file system, right?

adoption of new features will be an uphill battle

[dekeji]

ReiserFS is great, and this seems like a tasteful way of implementing some of the complex things people seem to want to do with file systems.

But I would feel uncomfortable relying on any of these features right now because any software that does would fail with any other file system. ReiserFS is free software, but you still end up needing to run software on other file systems in many cases.

I think for these features to become widely adopted, we need some kind of library-based emulation, something that uses ReiserFS if it runs on it and otherwise emulates ReiserFS features like files-as-directories in user mode on top of existing file systems (by using funny file names, etc., similar to UMSDOS).

Huh?

[Enahs]

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.

Re:Huh?

[timeOday]

I did a comparo of ReiserFS and Ext3 a while back and these were my main findings:

1) Reiser destroyed Ext3 for directories with many thousands of files in them. However, now you say ext3 has btree hash dirs, probably minimizing the difference
2) Resier was much more space efficient if the average file sizes on the filesystem is very small (say, well under 4k). However, no *real* filesystems I found were like this.
3) The two were about the same in speed for large numbers of small reads and writes.
4) Ext3 was a bit faster for big sustained reads/writes. But it wasn't a huge difference and might not apply to Reiser4.

In short, Reiser4 was more robust to unusual filesystem usage, at a slight penalty to normal usage.

In fairness, this is because Ext has been around for so long, it is optimized for normal usage, and software is tailored not to step on the toes of Ext's deficiencies. For instance, to store huge numbers of small files, people usually use a database of some sort (even if only flat file). Reiser opens the possibility of simplifying life by replacing simple databases of small records with the filesystem; for instance, it might be practical for a Usenet newsreader to store every cached message in a separate file.

But for the most part, I think Reiser will stand on its new gee-whiz features (plugins), rather than raw performance, since there are so many filesystems with roughly comparable performance for normal usage scenarios. As with Longhorn's fancy new filesystem, the question is whether people really want feature-rich files.

Re:Huh?

[hansreiser]

ext3 btrees are not well done performance wise. Most users are best off not using them, because they significantly slow performance unless directories are large, and I think that is why they are not on by default.

V3 of reiserfs paid a performance penalty for saving space and handling large directories efficiently. This irritated the shit out of me, the author, and we fixed it in V4 and then some.:)

V4 is finally to where it is sweet, and works like I fondly imagined earlier version of reiserfs would. We fixed deep design errors, and V4 is a complete rewrite from scratch reflecting all our regrets accumulated over 10 years of learning what the hell we were doing. We were beginners when we started out, as everyone is.

Now, the space savings makes things go faster not slower, and does not add seeks. We learned from XFS also, and allocation on flush works very well. Thanks SGI, for taking the time to explain to me why I should adopt allocation on flush in ReiserFS. XFS is a great filesystem.

Now that the performance advantage is ours for the now, and there aren't irritating flaws bothering me, we should and will move to semantic features not performance as our focus. The post above is right about that. Semantics matter more than performance.

Re:Huh?

[Negatyfus]

Looking at the benchmarks on the site, I was intrigued by Reiser4's performance when reading or writing more than one stream. It seems as though it performs almost the same as when you're reading or writing just one stream. Am I correcting in thinking that this would make one hell of a difference when, for example, you're running updatedb and then start Mozilla (which takes me forever with ext3)...?

This would be SO worth it.

Re:Huh?

[Lord Kano]

Hans, thank you. Thank you for all of the hard work and dedication to giving OSS/Free Software a better filesystem.

You are "one bad motherfucker". Keep up the good work. Are there any plans to bring Reiser4 to the 2.4.* kernel?

LK

Re:Huh?

[metamatic]

Reiser opens the possibility of simplifying life by replacing simple databases of small records with the filesystem; for instance, it might be practical for a Usenet newsreader to store every cached message in a separate file.

More to the point, it means ReiserFS is great for any system that's going to run a news server, which already does store every single article as a separate file.

It's also great for mail servers, because you can use Maildir without having to worry about performance, and Maildir is superior in every way to the hideous brokenness of mbox.

It's also great for Gentoo, where /usr/portage contains a ton of small files for every possible version of every package you might ever install.

In fact, it's not clear to me that ext3 is optimized more towards real world filesystem usage. Are there any actual studies of real world filesystem stats? Any open source tools we could run to assist in such studies?

In fact, it's not clear to me that ext3 is better optimized for normal usage.

Re:Huh?

[Anonymous Coward]

I did a comparo of ReiserFS and Ext3 a while back and these were my main findings:

[snip]

In short, Reiser4 was more robust to unusual filesystem usage, at a slight penalty to normal usage.

How did you do a comparison of Ext3 and ReiserFS v4 "a while back" when ReiserFS v4 just came out today?

I assume you mean that you compared an older version of ReiserFS (like v3) or a beta version of 4. That's kind of important to mention!

Re:here is the text from namesys.com

[Anonymous Coward]

Yes, but with the way they describe each filesystem, most people with no prior knowledge would probably go for Reiser since they make it sound 'best'.

MANIFESTO

[YetAnotherName]

Yes, that certainly comes across more like a manifesto than a detailed exposition of software architecture. I have to admit, reading through it, my KOOK Alert was almost reaching critical stages ... if they only included SOME ALL CAPS SECTIONS as well as a reference to Einstein, who was on the brink of making a similar discovery, but was forced to suppress it DUE TO GOVERNMENT INTERVENTION, then the KOOK alarms would be blaring and I'd've discounted the entire thing.

Now, all I'm interested in doing is exploring the potential of doing everything in the "manifesto" literary style. My next letter to the editor? Manifesto. My thank-you note to grandma? Manifesto. My resume? Manifesto. My next Slashdot posting? Manifesto.

Oh yes ... they never trusted me at the academy ... but they'll learn the hard way ... mwuahaha, er ... ha.

Re:MANIFESTO

[kundor]

But there WAS government intervention!

The government's funding them.
Sure sign of kookdom, that.

what are you talking about?

[dougnaka]

it sounds like you're referring to reiserfs as not compatible with programs? The only types of programs that wouldn't be compatible with reiser4 would be things like fsck that are designed for a file system.

You install reiser4 in your kernel, and start making file systems. You put programs on them and they work the same as they would on ext2/3/xfs/reiser3, except likely faster, and with atomic safety.

Re:what are you talking about?

[Chandon Seldon]

... unless you want to use any of the Reiser4 specific features.

Re:what are you talking about?

[noahm]

it sounds like you're referring to reiserfs as not compatible with programs? The only types of programs that wouldn't be compatible with reiser4 would be things like fsck that are designed for a file system.

Well, the Reiser4 plugin infrastructure allows for more functionality to be added to the filesystem. Depending on the plugins created, the processes accessing this filesystem may need to know about them. E.g. GNU tar is incapable of preserving extended attributes and ACLs when copying data. Or look at the NTFS streams feature. This kind of thing needs at least some support in userspace, or else it can't be accessed.

It will very much be possible for people to write code that needs to run on Reiser4 in order to work properly. It will be interesting to see if this happens, and if so, how widely adopted it becomes. I think there's a lot of potential here, but I understand how people might be reluctant...

noah

Re:what are you talking about?

[sirsnork]

I'm hanging out for a SQL pluging. Being able to "SELECT filename FROM filesystem WHERE size > 1000000" would be fantatstic (note very basic example). Not to mention meta data plugins that can index your media files and store that data in the filesystem (again with SQL access)

Re:what are you talking about?

[Nasarius]

Not to mention meta data plugins that can index your media files and store that data in the filesystem (again with SQL access)

Bad idea, I think. What happens when you want to backup your files or send them to someone else? Nah, that kind of metadata is best handled outside the fs itself. Switch to file formats that allow for more flexible tags (*cough* OGG *cough*).

Re:what are you talking about?

[Anonymous Coward]

What about it? Use a proper archival format that can archive the extended data, such as STAR or ZIP.

Switch to file formats that allow for more flexible tags

Thats not only a very silly suggestion (How do you add "tags" to a text file?) it is also a very poor solution (How do you index all these tags across different formats?) Such half-assed solutions are why Linux is a disjointed mess.

Re:what are you talking about?

[Anonymous Coward]

Bad idea, I think. What happens when you want to backup your files or send them to someone else?

For example, you could keep song mp3s in a file/directory with a custom plug-in; the directory will contain the mp3 stream and as many metadata files you want (like name, etc). If the media player knows about reiserfs, it will use the dir content. If it doesn't it will try to access the song as a file, and the plugin will automatically assemble an mp3 file with ID1+IDv3 and all sorts of in-line tags.

Re:here is the text from namesys.com

[drinkypoo]

Actually they give the easy option of ext2/3, xfs, reiser, and jfs, and really it's no harder to use any other filesystem - though why would you want to? - that is fully supported by linux including support from some bootloader. Pick your filesystems, emerge the proper tools, make your filesystems, and keep going. Admittedly, they only document the steps for xfs, jfs, ext3, and reiser.

Encrypted filesystems

[SteamyMobile]

Finally, we have a way of having an encrypted FS in Linux that's not an ugly kludge like loopback. The modular system is great because we can add encryption, access control, all kinds of things without having to go through the trouble of writing an FS from scratch.

It's very disappointing that it took Linux all these years to get something as basic as a secure, encrypted way to store files. Even Windows has had FS encryption for a while.

The next release of Suse is going to be a doozy. KDE 3.3, Reiser 4.

Re:Encrypted filesystems

[Anonymous Coward]

i was about to nail you for this, but lethyos already did a great job. dude, get your facts straight then you may distort them at your leisure

Re:Encrypted filesystems

[Anonymous Coward]

Encrypting entire file systems are overrated. It's only in very rare cases that they would be remotely usefull.

Like on a laptop with sensitive data... And that's about it, unless your worried about somebody breaking into the datacenter and making off with your servers.

The nice thing about encrypted loopback file systems is that when not in use they are not apparent wtf they are. You have sensitive data? Stick it in a loopback filesystem, unmount it, and then disquise it as a big core dump from Mozilla or something in your home directory.

Who is going to notice?

Plus with a encrypted FS, and if you system reaches a unstable or unbootable state then the barriers you erected to prevent people from reading your data if they gained access to your machine is the same barriers that you may now have to break in order to get your valuable data back.

To much work, to much to risk, for such a limited gain.

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:How reliable is an "unstable 1.0" anyway?

[mrchaotica]

Sorry, I can't resist picking a nit...

This is a FOUR-point-oh(4.0) release, not a 1.0. (granted, that's still an X.0, so don't use it on servers yet, but still...

Re:How reliable is an "unstable 1.0" anyway?

[hansreiser]

Our approach is to first get it to where nobody in the developer team using all known filesystem crashing scripts collected over 10 years can crash it, and then ask our mailing list to crash it, and only then ask real users to try it.

That said, if you have a mission critical server, be sensible, wait a bit.

It is in the -mm kernel, if it goes without a bug report for a week, we send it to Linus. I hav been surprised by the lack of bug reports after going into -mm. All we have is one apache 2 bug report that we cannot reproduce yet.

LVM2

[Anonymous Coward]

Would ReiserFS 4 work with LVM2?

Re:LVM2

[Lethyos]

Flesystems do not typically care about what the underlying device is (of course I'm not talking about "filesystems" devoting to the task of distributing the storage mechanism, such as NFS, AFS, CODA, and friends). Device access is handled at a "lower level" by drivers, I/O, etc. In otherwords, with Unix at least, a device capable of storing bits (including metadata about how to store that information, AKA a filesystem) is presented to the user and what's actually behind it is unimportant. It could be a hard disk, a chunk of physical RAM, a RAID array, a floppy disk, or a even another file sitting on an existing file system. To get a better idea for how all this works, read up on losetup which is available on pretty much any Linux system (assuming support for the loopback device is present in the kernel... which it should be).

Re:LVM2

[Anonymous Coward]

Thanks, your answer really helped.

Re:here is the text from namesys.com

[auzy]

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..

Re:here is the text from namesys.com

[Anonymous Coward]

His New Filesystem Is Unstoppable!!

atomic v. journaled

[Anonymous Coward]

Is Reiser V4 journaled? Is an 'atomic filesystem' the same, or is it better, or just different?

If different, what is the difference?

(it feels like those questions could be factored into one, better, question, but I can't do it in my head right now ...)

Re:atomic v. journaled

[Jetson]

Is Reiser V4 journaled? Is an 'atomic filesystem' the same, or is it better, or just different? If different, what is the difference?

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...

Microsoft simply copied it from IBM

[clem.dickey]

(The parochialism, not the file system.)

Transactions?

[ceswiedler]

How large (and long) can Reiser atomic transactions be?

Can I write an installation program which creates, replaces, moves, and deletes many files and directories, and have it all be under one transaction with a single commit at the end? Do other 'sessions' not see the transaction until it is complete? Are sessions based on processes or threads or something else?

That would be pretty amazing, to be able to roll back large sets of changes in case of an error. I know that database rollbacks can take large amounts of time (they optimize for the commit, which makes perfect sense) but nonetheless having rollback support in applications would be sensational.

Re:Transactions?

[Qzukk]

I suspect (knowing how the OS and development works) that a transaction is limited to a single operation.

You can create a file, and that file will either be created or not created, but not in a midway state. You can write data to a file (which incidentially updates metadata) and the metadata and new data will either be written or not written. Etc.

Creating transactions that span more than one operation would require changes to the way userspace programs interact with the filesystem. Not to say it couldn't be done, but not with the standard open()/write()/etc. calls.

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.

Re:Transactions?

[Anonymous Coward]

It may be possible to implement rollbacks of a large nature, but the first problem that will be encountered is the issue of filesystem locking to maintain consistancy. To do a fully atomic operation, all files that are going to be read or written must be locked against other modifications until after the transaction is complete. One thing this means is that all applications will have to support the locking semantics, otherwise there is a possibility of applications deadlocking. You don't want to be doing a large commit on /etc or /var for instance and have all sorts of deamons (or the kernel) deadlocking, crashing, or hanging because of lock issues. Performance is another problem, because locking files for a five minute install could hang up anything from "fortune" to "inetd". The other problem that can occur with transactional installers is the need to lock an arbitrary set of files after beginning an installation, and hence already having locked files. Deadlocks are even more prevalent in software that explicitly uses locking and fails to consider corner cases and how to back out of them. A sure-fire way to prevent these types of deadlocks is to only hold a single set of locked files at any given point in time, and only lock or unlock that set in its entirety. This can lead to over-locking, which leads to lots of busywaiting or timeout failures.

Versioning filesystems can give the advantage of consistent cross-sections of a filesystem at any point in time to individual applications, but applications still have to be specially designed to properly lock their own files and maintain internal consistancy with the application, especially with regards to using the appropriate version of a file. In the long term, object versioning will probably become the norm, since it allows large transactions without some of the bottlenecks and deadlock issues. But a general solution to the problem of locking and consistancy may be undecidable in theory anyway.

Re:Transactions?

[hansreiser]

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.

Re:Transactions?

[ozbird]

I tried using the term "transcrash" instead of atom, but no one but me loved the term.

How about "subatomic"?

Re:Transactions?

[Anonymous Coward]

Hans, can you now please explain, is atomicity enough to expect that the ReiserFS will survive power out, or not?

In short, is it without "data logging" as safe as NTFS or is it still not?

I understood that it is not?

Thanks.

Re:Transactions?

[ignavusincognitus]

On the surface, this sounds similar to FreeBSD's softupdates. Can you explain how the two approaches differ?

Re:Transactions?

[chtephan]

Hans, can you now please explain, is atomicity enough to expect that the ReiserFS will survive power out, or not? Yes, that's exactly what "atomicity" refers to. After a crash you'll find the filesystem in a consistent state. You'll either find an atom fully commited or not.

In short, is it without "data logging" as safe as NTFS or is it still not?

It's safer than NTFS. Because it's fully atomical (well, in respect to crashes, no isolation at runtime), NTFS is not. Other linux filesystems (ext3, reiserfs v3) usually distinguish between, data=writeback, data=ordered and data=journal. The first two are just guaranteeing atomicity for metadata writes, only the last one for everything. reiser4 is atomic by default (because it's not a journal bolted on, but by atomic by design), that means it's as safe as data=journal, just without the journalling overhead most of the time.

Re:Transactions?

[danalien]

This has nothing to do with Parent or GrandParent, a completely different thing.

DISCLAMIR: haven't used reiserfs (extensively that I'd say I know reiserfs. I've done one suse test-install with reiserFS, hardly qualifies ...)

I was wondering if reiser4 could do:

• It's like so I happen to have a few infamous IBM Desktop GXP75's - where some have shown that they have bad blocks.

• What I was wondering, does reiser4 do: "mark bad blocks it finds under the/a extensive format as unusable"?

  apart from the (few) bad blocks the drive(s) work flawlessly - and it'd be a damn shame of a waste to replace them, because one couldn't tell the FS/kernel "don't go there/use those damn blocks!" - to my knowledge, most FS's have an option to check for 'bad blocks' but none are 'smrt' enought to leave them out when creating the FS...

  Of course, it could be argued to use IBM's DFT to remap the bad blocks internally, but for some reason even that fails... (can't recall the error msg forehand) ... but it could be it finds to many bad blocks, and it hasn't enough 'spare blocks' to remap em' to - to which of course my initial reply whould be, "how about just marking them unsuable for eternity? and yes, even if I loose some space doing so ...."

  At last, after writing this - I'm left pondering: Ok, maybe "leaving em' out"/"creating the FS around" the 'bad blocks' woludn't work; *this* 'dancnig threes' ... *hum*, what about during an extensive format 'isolate & wrap in' 'bad blocks' into a file(s?), and mark it so that the Kernel/OS/FS is never ever allowed to access this file? Additionally, one can't prevent 'bad blocks' from ever starting occurring (at most/best, we could prelong the inneverable of happing sooner...) - but one could at least provide a solution to work around future occurring 'bad blocks' by adding them to the file(s?) this way.

...*ok, enough blurbbing nonsense*

/* btw, my handy work-around, was to divide the drive into parts, do an (ext3) extensive format .. and that way start to pin-point where on the drive the blocks where located ... etc etc, and finally not mount the effected parts (of course, I did combine the unaffected 'parts' into one partition, at the end ...) ... */

Re:Transactions?

[Daniel Phillips]

Our atomicity does not provide isolation or rollback, it is only atomic in the sense of whether it survives a crash.

Hi Hans,

That's called "durable", the D in ACID.

By the way, huge props for getting R4 out the door and into -mm.

Regards,

Daniel

User Report

[vandan]

I've been using reiser4 for quite some time here at work. I'm booting from a 'redeeman' boot disk ( Gentoo hacker ) and then installing Gentoo unstable onto our work PCs :)

It rocks. Very, very fast. Whereas an:

emerge -up --deep system

would have taken about 20 seconds to run under reiser3, it takes about 5 seconds under reiser4. Very impressive.

I haven't had any stability issues with it. There were ( last time I checked ) 2 outstanding bugs - one nfs ( files on server with reiser4 ) bug, and one strange bug that made adn OpenOffice compile fail miserably. Bug (1) doesn't affect us, as our nfs server is running reiser3, and bug (2) I got around by creating a reiser3 partition, mounting /var/tmp/portage on it, emerging OpenOffice, and building a package of it for all the other PCs.

I just can't get over how fast it is.

Re:User Report

[Anonymous Coward]

Would some kind soul explain why the above is funny?

Re:User Report

[Anonymous Coward]

I don't get it either....

Re:User Report

[hansreiser]

I think those bugs were fixed a while ago.

Re:User Report

[Anonymous Coward]

Save 0.63 seconds of your life and shorten --deep to -D: emerge -puD whatever

Re:User Report

[Anonymous Coward]

Or the slashdot version

emerge -Dup

Re:interesting

[scooviduvoctagon]

Oh I forgot to mention - it becomes very obvious as to why Stallman is/was so obsessed with making everyone call Linux: "GNU/Linux" ... strictly for mindshare.

Boot CD with reiser4progs 1.0

[bulletman]

Over the past few days (ever since reiser4 was accepted into the mm kernels) I've been looking for a boot CD with reiser4progs 1.0. I want to try reiser4, but need a boot CD to format my new drives and mount my current partitions for copying.

The only boot CD I was able to find was the (R)ecovery (I)s (P)ossible Linux rescue system:

http://www.tux.org/pub/people/kent-robotti/loopl in ux/rip/

It was released yesterday (22 Aug) and is still warm to the touch.

Stephen

Re:Boot CD with reiser4progs 1.0

[catch23]

Ever try debian from scratch? Their boot cd has all kinds of good stuff... and if the boot cd didn't have everything you needed, all I had to do was modify a small config file to build my own bootable iso. Used their CD to build a reiser4-SATA-SCSI Raid configuration.

Custer book

[harmonica]

Original site is slashdotted, so I only comment on your quote.

I read that Custer book years ago. IIRC, its major problem is the simple fact that it's very superficial for a book entirely devoted to a file system. There is no way anyone could program a file system driver using that book. Which is no coincidence, given Microsofts usual lack of proper documentation of their data formats. But: There also is little practical information on using NTFS as an end user or a developer. Which, back then, left me wondering for whom that book was written in the first place.

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.

ENT-ertaining...

[tepples]

Dancing trees? Now that's ent-ertainment!

</lotr>

Anybody know how to ghost it?

[bad_source_BIOS]

Is there any way to image this or any Reiser partition?

Re:Anybody know how to ghost it?

[Wesley Felter]

I find dd works well with all filesystems.

Re:Anybody know how to ghost it?

[tsarin]

Um, dd if=/dev/partition bs=1m | bzip2 > ghost.bz2, maybe?

Re:Anybody know how to ghost it?

[Lethyos]

When you image a device, you're not imaging data selectively, you're just getting whatever is there. In otherwords, you don't care what's on the disk, just that you are reading bits off of it sequentially.

Real world example: if I run dd if=/dev/hda it will (in addition to spewing bytes to stdout) start at the very first bit on the disk and continue reading the next after the next until the disk reports (specifically, the disk driver) that there are no more bits to be read. Whether or not that disk happens to be formatted with reiserfs or NTFS is irrelevant.

It is in this way that tools like dd or Ghost back-up and restore a disk exactly how you see it at the time of imaging.

(Cool tip: you don't need Ghost to take a disk image and store it across a network. All you need is dd, ssh and a target machine running the SSH daemon. Run: dd if=<the device to image> | ssh <user>@<target host> "cat > backup.img" . There are tweaks you can do to improve the performance of that (such as setting a larger block size on dd), but that is an exercise left to the reader.)

Re:Anybody know how to ghost it?

[chizu]

I think you're looking for partimage.

Re:Anybody know how to ghost it?

[grumbel]

In addition to that I would recomment to have a look at PartImage, it basically does a similar job to 'dd', but it is 'filesystem-aware', thus it is able to save only the used blocks of the disk and not forced to everything. Especially with todays 120gb drives the saving can be quite huge.

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:EVERY computer needs a u.p.s.

[Anonymous Coward]

"If you object to "hacker" being used instead of "cracker", then why do you "surf" and not "browse" the Internet?"

I don't do either. I surf (and browse) the Web. It's hard to surf e-mail.

Re:EVERY computer needs a u.p.s.

[JohnFluxx]

Just to add to this..
Make sure that if you buy a very cheap one, that it does run from mains->battery->computer, and not mains->computer, with battery outside the loop.

With the battery in the middle, it means the output is isolated from any nastyness in the input.
Electric mains is +10%V normally - that's a difference of around 20V in just normal operation.

Re:EVERY computer needs a u.p.s.

[Shimbo]

"EVERY computer needs an uninterruptible power supply. EVERY one."

It depends on the quality of your power supply, to some degree. I would have thought I personally average about 5 years between mains power outs; that's likely more than the lifetime of the typical PC.

Adding a UPS is also adding another point of failure; I have seen a UPS fail and trip offline for no reason at all.

You're probably right, in that a lot of people run serious servers without a UPS, that could use one. Just not everybody.

Re:EVERY computer needs a u.p.s.

[Anonymous Coward]

> "EVERY computer needs an uninterruptible power supply. EVERY one."

As someone who has replaced over a dozen UPS's or UPS batteries in the past two months, I have to disagree that a low-end (what you were talking about) UPS is the solution. I think we've only lost a single power supply and maybe two monitors in the past 10 years to a power surge, but in just the past two months we've had downtime on over a dozen PC's due to problems with a UPS. With the Chinese batteries in the new UPS's, you typically only get a year or two of life out of them. We're replacing them with Panasonics, which helps, but it isn't a complete solution. The individual UPS's aren't online, so they only offer the same protection as a surge protector. You're better-off putting that money into a whole-building surge protector. In our colo, we and the owner do not have UPS's on our systems. The power has only been off once in the past two years, so we would have had more problems due to a UPS than that.

The real solution is to use one of the decent online (runs off batteries 24/7) data system UPS's for the entire building, but that requires running wire for separate outlets in each office so that's not doable for most people. They do that where my wife works. They only have downtime about once a year for battery replacements. Another secret is to use an automatic transfer switch to connect directly to utility power if the UPS quits. That's saved them a couple of times. The switches are fast enough so that most PC's don't have a problem. They simply replaced the power supplies that do have a problem.

Re:EVERY computer needs a u.p.s.

[pacc]

Well, every computer I use ought to take
a simple push on the powerbutton when I go
to bed if I forgot to login, su and "shutdown -h now".

"User errors" don't exist, though I could need an atomic filsystem from time to time...

Re:EVERY computer needs a u.p.s.

[bfields]

"EVERY computer needs an uninterruptible power supply. EVERY one."

It depends. You have to estimate a) the costs of buying and maintaining UPS's (batteries don't last forever!) per year versus b) the expected loss due to power problems in a year (the sum of the chances of various kinds of accidents times the probability of each kind of accident occuring in one year).

It would cost me about $600 to replace my desktop's hardware (I'm not including the monitor, which I'm assuming most people don't keep on backup anyway). I keep frequent enough backups that the amount of lost data is unlikely to be significant. So the costs of a power disaster would be at most $600 plus the cost of the time required to restore.

In the approximately years I've maintained my own computers, I've never lost anything due to power problems. I'm certainly not saying that it doesn't happen; some day I fully expect that it *will* happen. But at this point I'd need several major accidents to get to the point where the cost of UPS's over the last 15 years would have been worthwhile.

For people with more expensive hardware, the calculation may come out differently; but for people with good backups and cheap consumer hardware, I doubt it's usually worth it. As computer prices continue to fall, this will increasingly be true.

--Bruce Fields

Re:EVERY computer needs a u.p.s.

[b0bby]

I had a client whose main Netware server had 450+ days uptime when we finally took it down to add a UPS. They never ever seemed to lose power.

Re:EVERY computer needs a u.p.s.

[LaCosaNostradamus]

Have you ever seen a UPS causea power problem? I have. Hence, adding a UPS to every machine is just asking for problems per se. The thing to do is figure out which machines actually need power protection, and then figure out how a building-based UPS fits into the equation.

Add to this the fact that power protection is often implemented in "surges" (i.e. tech fads, like how PDAs were implemented). After some years, nobody knows if the damned things are even working, and certainly no one knows how to get parts for them. "Where are the manuals?" and "What does that amber light mean?" are often-heard phrases in this era.

If you have a lot of small clients who have little interaction with their buildings, then yes, individual UPSes might be the best answer. But a surge protector and RAID on the server may be the best options, for price, applicability and maintainability.

Re:EVERY computer needs a u.p.s.

[FrankHaynes]

Funny you should ask that.

This past week I was shutting down this here Win2k system when I was done with it because my APC 450 V.A. u.p.s. had exhausted its second set of batteries and would not hold through these brief power glitches (likely caused by Florida Power and Light cutting in replacement transformers around here) that we have been getting.[1]

A buddy gave me a large u.p.s. that had been in commercial service, so I hooked up two 12 volt deep cycle marine batteries in series to it and it fired up fine. Right while I was reading /. last night POW! the thing just shuts down a.c. output on me for no friggin reason. Yes, I was very upset.[2]

Nonetheless, I stand by my assertion unwaveringly. I was primarily thinking of power outages lasting no more than a few seconds, which are the most common where I have lived and worked. These are more troubling because they leave hardware gates and c.p.u.s in unknown states due to their brevity and result in the "wierdness" that I spoke of in my original post.

You are free to calculate a costs/benefits analysis of replacement hardware under a scenario in which a power failure fried your motherboard, but no matter how good you are at backups, if you actually *use* your computer you will have data that has not yet been backed up. I don't know about you, but my time is far more valuable than this pile of P.L.A.s and capacitors and printed circuits and I don't want to add to the potential to waste that time by going without a u.p.s. and suffering the ensuing headaches. A u.p.s. is a very worthwhile investment, as is a r.a.i.d. and other enhancements.

The primary reason for posting my original comments is that I assume that most subscribers here are software types, so they probably don't have the interest in or experience with these hardware considerations. Words to the wise; the rest can suffer.

SO: when you read a proponent of ReiserFS claim "Well, my ext3 fs lost data on me so it's no better than ReiserFS", ask them if they had a u.p.s. supplying clean power to the box running ext3 before jumping to any conclusions. Back on topic.

***

[1] By the way, turning the machine on and off places it under greater thermal stresses from heating and cooling cycles, thus shortening the life of box. My machine normally stays on all the time.

[2] This has happened about a dozen times to this NTFS in the past week and I haven't lost any data; I'm wondering about the motives of the subscriber who earlier commented that NTFS is the worst file system of all the ones being discussed here.

Re:EVERY computer needs a u.p.s.

[lawpoop]

What brand/model do you recommend?

Re:EVERY computer needs a u.p.s.

[Anonymous Coward]

Couldn't agree enough. Even where electrical power is very stable, there's still noise on the line from appliances and such. If you ever experience weird lockups, before rushing to blame the drivers/OS/software, try installing a UPS. I didn't believe it at first either, but it does seem to work, time and time again.

Re:EVERY computer needs a u.p.s.

[Anonymous Coward]

Exactly. Too many people blindly recommend adding points of failure and complexity without thinking about the consequences. At the engineering company I work for, we've had hundreds of UPS's quit, many that get flakey (especially the circuit breaker on the back of APC's), many unexpected shutdowns due to NT thinking the battery was dead when it wasn't, and of course a large number of premature battery failures. We've even had a couple of fires that started from Best UPS's. I just checked with the nurse, and we've had over 50 hours of lost time accidents due to UPS problems (usually sulfuric acid burns from leaking batteries) in the past 10 years. I think the power has been off in this building only fix or six times in the past three years, and that only takes a few minutes to get people back up and running afterwards so not having them isn't that bad. It would make more sense and cost much less to just leave the machines without a UPS. As it is now, the newer half of the machines don't have one. Even

Re:EVERY computer needs a u.p.s.

[JerkBoB]

It depends on the quality of your power supply, to some degree. I would have thought I personally average about 5 years between mains power outs;

The interesting thing is, though, that a good UPS will protect your gear from more than just blackouts. I run apcupsd on my various machines (talks to the UPS via the USB cable included) and I get notices about brownouts and surges that I woudn't otherwise have noticed (clock on the coffeemaker isn't blinking, etc.). Granted, I live in Maine, and the electrical grid here probably hasn't been upgraded in 50 years, but I've seen similar behavior in different locations.

Adding a UPS is also adding another point of failure; I have seen a UPS fail and trip offline for no reason at all.

It's true that the UPS is another POF, but on the other hand, what do you think the likelihood of the UPS failing is compared to the likelihood of getting weird power on the line? For the record, I've never seen an APC UPS just die. I've seen them lose their battery and beep every 6 hours, but that's to be expected. I'm not invalidating your experience, just stating that in my experience with hundreds of APC UPSes of varying capacities, I've never seen that.

Re:here is the text from namesys.com

[Anonymous Coward]

But I want to install to a tempfs filesystem dammit. They are SO fast!

Heres a Copy (albeit a bad one)

[matz62]

Reasons why Reiser4 is great for you:

* Reiser4 is the fastest filesystem, and here are the benchmarks.
* Reiser4 is an atomic filesystem, which means that your filesystem operations either entirely occur, or they entirely don't, and they don't corrupt due to half occuring. We do this without significant performance losses, because we invented algorithms to do it without copying the data twice.
* Reiser4 uses dancing trees, which obsolete the balanced tree algorithms used in databases (see farther down). This makes Reiser4 more space efficient than other filesystems because we squish small files together rather than wasting space due to block alignment like they do. It also means that Reiser4 scales better than any other filesystem. Do you want a million files in a directory, and want to create them fast? No problem.
* Reiser4 is based on plugins, which means that it will attract many outside contributors, and you'll be able to upgrade to their innovations without reformatting your disk. If you like to code, you'll really like plugins....
* Reiser4 is architected for military grade security. You'll find it is easy to audit the code, and that assertions guard the entrance to every function.

V3 of reiserfs is used as the default filesystem for SuSE, Lindows, FTOSX and Gentoo. We don't touch the V3 code except to fix a bug, and as a result we don't get bug reports for the current mainstream kernel version. It shipped before the other journaling filesystems for Linux, and is the most stable of them as a result of having been out the longest. We must caution that just as Linux 2.6 is not yet as stable as Linux 2.4, it will also be some substantial time before V4 is as stable as V3.

Comment removed

[account_deleted]

Comment removed based on user account deletion

You mean...

[IcEMaN252]

...you can get a copy of Linux Format? My B&N is always sold out!

Re:You mean...

[Anonymous Coward]

Heres a juicy snipet of information for you: Linux Format is a UK magazine, published by a UK publisher, in the UK. Some Slashdot posters live in the UK. Therefore, some Slashdot posters can obtain a copy of Linux Format from their nearest news agents.

Why ReiserFS is worth using

[bigberk]

Earlier this summer I posted this article on USENET describing why ReiserFS is an incredible file system. That was version 3, so I'm curious how version 4 improves on this. Stability is key and v3 has reached stability. We can expect v4 to take longer, so be ready for growing pains -- but I'm very optimistic about ReiserFS in general. I think Hans has the right idea about what a filesystem 'should' do!

Re:Why ReiserFS is worth using

[Junta]

Reiser? Stable? Now those are two words that don't belong in the same sentence.

In dealing with ext3, JFS, and XFS, Reiser has proved the most annoying because first, I have to do a full fsck on it most frequently, and second, a quarter of the time it is the root fs and needs rebuild-tree, which is annoying as freaking hell because you can't even have it mounted read-only. XFS I've had issues with two, but never having to completely umount to fsck. JFS has issues where it's journalling doesn't seem to catch something and it later in the middle of operating, figures out it is inconsistant and remounts read-only for fsck, which is also highly annoying. In all cases, get ready to dig through lost+found and figure out what filenames those inodes used to be associated with.

If you seek stablity (which is extremely key for filesystems), the only way I've found to work is ext3. It is a real slug (a *real* slug), but I would trust it much more readily than any other fs.

Re:Why ReiserFS is worth using

[SaDan]

Usually, unstable Reiser filesystems point towards misconfigured or faulty hardware.

I maintain ReiserFS v3 filesystems on terabyte arrays, on database servers, and on our machines that go out to client sites. ReiserFS has performed very well for my company. We are a 24/7/365 shop. Downtime isn't in our vocabulary.

Re:Why ReiserFS is worth using

[0x0d0a]

I've always used ext3 for exactly that reason -- I had a friend who watched his reiser3 filesystem eat itself, started printing screenfuls of garbage at boot. Ext3's pretty mature, and it's mostly ext2 code (which is *really* mature).

Dunno about speed, but I just run lightweight server and desktop stuff on the machine, and as long as my disk doesn't go to hell, I'm pretty happy.

Besides, most people are used to stuff like NTFS or even FAT, and any modern filesystem comes off as pretty nice anyway.

I'll give reiser4 a year or so and then try it out, unless folks are talking about problems. Filesystems are the one area where bugginess is really nasty and testing is no fun.

Re:Why ReiserFS is worth using

[kaltan]

[ ... Reiser has proved the most annoying because first, I have to do a full fsck on it most frequently, and second, a quarter of the time it is the root fs and needs rebuild-tree, which is annoying as freaking hell because you can't even have it mounted read-only... ]

You might want to check your hardware in that case. I'm using reiser3 for years and it only failed when the hardware went broke ( and then it went down very hard ). Check for DMA errors in your syslog and use the smartd or smartctl -a /dev/hda tool to diagnose your drive. My two reiser-crashes requiring a rebuild-tree were a to hot harddrive and a to long IDE cable causing DMA CRC errors and worse.

Re:Why ReiserFS is worth using

[Junta]

But here is the reason why I take most Reiser advocates with a grain of salt (beyond my own experience), they always seem to have it on 'important systems', which generally means you are connected to UPS and don't push the system to sudden downtime.

As far as filesystems working when they are allowed to run endlessly or only stopped in an organized unmount or remount read-only, I'm hard-pressed to think of a modern filesystem that has a problem.

However, I administer many many servers, and they are pushed to the limit in many ways. When you have a small, controllable sample to base your views on that is in a really nice situation with respect to uncontrolled shutdown, it isn't a particularly useful circumstance for speaking on reliability. Just for your knowledge, 99% of the systems are hardware-fault tolerant, and the failures follow the reiser filesystem when things are reorganized. Now Reiser4 with the atomic operations may change this if they do what they say, and I'll be interesting to try it out, but I don't hold my hopes too high.

Re:Why ReiserFS is worth using

[Junta]

I'm using Reiser on many many systems, >90% on SCSI RAID arrays. Faulty drives, of course, occur sporadically across reiser and non-reiser fs alike, but we replace and rebuild long before we lose two drives.

The difference in circumstance between me and people who swear by reiser is that those who swear by reiser always seem to be in a circumstance to rarely deal with unclean shutdown, whereas in this situation, (testing), we frequently intentionally do unclean shutdowns to simulate events such as power loss, and we have many many systems (~512) that we do such testing on, so problems are maginified by a significant amount.

Re:Why ReiserFS is worth using

[metamatic]

I have three servers and two desktops running on Reiser3. None of the servers are on UPSs, all have had power failures. None have had filesystem corruption as a result. Two systems are RAID-5 arrays, one's a regular single hard drive with a ReiserFS root. The RAID-5 servers are used by hundreds of people around the world every day, and have active processes writing data 24/7. They're all 2.6.x kernel.

However, none of the systems are RedHat. As mentioned elsewhere in this discussion, RedHat kinda sabotage RieserFS, either through neglect or design.

Re:Why ReiserFS is worth using

[Creepy Crawler]

Oh well..

ALl I know when I was playing with a new filesystem (reiserFS), things went well. I ususally used good ol' EXT2 for my server. I had no reason to play around with it, but the hd died, so I had to re-animate it.

I did have the idiotic problems like not adding support for my FS (whoops ;), but all was well, after that.

A few months later, the box starts making continual HD noises while im using the machine (xfering a mpeg). Windows waits forever with the copying dialog. I hop over to the server to see what happened. / is ok.. /home is ok.. /usr is now a file, not a directory ;(

Well, I hopped up on the web to see what in the heck this was. Then I found out that the older slackware used the buggy ReiserFS version that when 2 unique ID's collide, things go "boom".

As of now though, I have a *fixed* version of reiserFS. It's been on there happily for about a year now.

Re:Why ReiserFS is worth using

[Junta]

Well, on the ~512 cluster nodes I play with afflicted with reiserfs (SLES8 SP3), I see ever so often in an unclean shutdown the problems mentioned. Sometimes it takes a significant sample size to get good statistical evidence of crappiness. Again, I reiterate my hopes that Reiser4 is architected better and less amatuerish and avoids the problems I've seen plague Reiser3..

Re:Why ReiserFS is worth using

[SaDan]

I administer one location that has serious backup power capabilities (2 weeks uptime on the batteries alone for the entire building, and a diesel generator with an underground 1500 gallon fuel tank), another that has minimal battery backup, and MANY that have no battery backup.

Loads of power hits every year, haven't had a single instance where ReiserFS failed. I've had machines catch fire after lightning hits, cleaning crews dumping water on power strips, vandalism afterhours, you name it. Machines take a beating where I work.

I know there are people who have done everything right, and still end up with problems using ReiserFS. I know that my situation is probably not the norm. But I also know that I'm very happy with ReiserFS, and so are my clients and coworkers.

I stated this before, and I'll say it again... ReiserFS tends to bring the WORST out of faulty or misconfigured hardware. Nothing will save you from a bad IDE cable, a flaky power supply, or an overheating CPU.

Okay, how about a WinXP driver

[Anonymous Coward]

I'm serious. If we can't have a production-ready NTFS driver for linux, how about going the other way, and giving us a reiserfs driver for windows?

Re:Okay, how about a WinXP driver

[macz]

Besides that crappy HPFS driver from OS/2 are there any non MS filesystem drivers anywhere? NFS doesn't count because it is a "Network" file system.

If you don't want FAT16, FAT32, NTFS (4 or 5), or the OS2 thingy, aren't you out of luck? How would you even install it? Much less mount it, format it, or take advantage of it.

I am not being facetious either, I really want to know

Re:Okay, how about a WinXP driver

[awehttam]

Why don't you write an Installable File System driver first, then report back to us here. ;)

As far as formating it goes, possibly the same way you'd format a PGP disk.

Re: hash collisions

[Anonymous Coward]

There is such a thing as a perfect hash ...

Re:Moron

[Anonymous Coward]

" If all the white people in Idaho decided to move to my city and work for 10 cents an hour, I'd be equally pissed about it. "

Dude, I'd be hiring 'em!

I'm so scared of Reiser* now

[AGTiny]

It was a day like any other and my 240GB RAID5 ReiserFS mp3 partition was just minding its own business... a split second power outage later and my precious data was vomited into tens of thousands of nightmarish numeric lost+found files. What I did manage to recover through painstaking use of mp3info, grep, prayer, etc. seemed fine, except for the insidious corrupted block of data that would invariably be within each and every one of my mp3 files. I nearly cried. At least I had an excuse to re-rip all of my CDs in Ogg format now.

The moral of the story: ext3 with data journaling (mount option data=journal), and a UPS are wonderful things. I can power cycle my box all day long with no ill effects (to my files anyway).

You better believe I am staying far far away from Reiser4!

Re:I'm so scared of Reiser* now

[Anonymous Coward]

You must have made something *very* stupid. It wont corrupt the data if you were not using it. Thats a *fact*. The chances are greater that YOU corrupted the data.

Re:I'm so scared of Reiser* now

[BenjyD]

I've had the same problem. A new Slack-10 install on a reiserfs partition locked up when I started X with the wrong configuration. I hit reset, booted up and suddenly KDE complains that half its configuration files are corrupt, despite fsck saying everything was fine.

Uh, excuse me?

[Lethyos]

Finally, we have a way of having an encrypted FS in Linux that's not an ugly kludge like loopback.

I think you misunderstand, that's the beauty of it. Basically, Linux (and FreeBSD with GBDE) allows you to encrypt a device at the block level. Everything is written to the disk encrypted, including the file system itself and not just the data. This also allows you to abstract the device. It could be a big file sitting on an existing device or the device itself. It's very flexible.

Some of the other advantages of this are fairly important. Here's a few off the top of my head.

1. It is easier to build a more secure and more reliable encryption system that works with all means of storing to a device rather than an encryption system for every one of those means. (1 versus an arbitrary number.) To simplify to more practical terms, it is better to write one encryption mechanism that can work with 10 file systems rather than 10 encryption mechanisms to work with each of those.
2. If you want to encrypt data, you might not always be writing a filesystem to a device. If I have a database that makes raw access to a device for its storage, but I want encryption, I need it at the block device level.
3. You do not want to make the file system any more complicated than it needs to be. Adding encryption would produce a disaster. Aside from making it easier to corrupt data, you lose a great deal of performance and security. How? Let's say you encrypted your data and sorted or indexed it by the plaintext. You are giving lots of clues to a potential attacker regarding the contents. If you do not follow this convention, you have to decrypt every byte to figure out whether or not its what you want. Horrible! (This may be an over-simplification. Anyone care to check me on this? Still, the basic principle should apply.)
4. Keeping encryption outside the filesystem makes it easy, even trivial to arbitrarily choose the cypher, the key size, and even the block size. The filesystem would undoubtably impose limitations on all these choices if the encryption were built in.

On the plus-side, filesystem level encryption lets you choose to encrypt on an as-needed basis (such as with NTFS), but the uses of this are minimal and questionable at best (what about swap, temporary files, and data that you forget to encrypt?)

all kinds of things without having to go through the trouble of writing an FS from scratch.

I think you may have learned from my previous comments how you accomplish this. Hint: you don't encrypt at the filesystem layer.

It's very disappointing that it took Linux all these years to get something as basic as a secure, encrypted way to store files. Even Windows has had FS encryption for a while.

Using the loopback device to encrypt data has been available for longer than NTFS has had encryption.

Re:Uh, excuse me?

[Anonymous Coward]

1. It is easier to build a more secure and more reliable encryption system that works with all means of storing to a device rather than an encryption system for every one of those means. (1 versus an arbitrary number.) To simplify to more practical terms, it is better to write one encryption mechanism that can work with 10 file systems rather than 10 encryption mechanisms to work with each of those.

wouldnt it be better if you had a bunch of things to getting attacked instead of just one? it seems like itd be weaker taht way

Re:Uh, excuse me?

[glitchvern]

Is there a way to mount the loopback device as a non-root user under linux (and for that matter any of the bsds)? If not, being able to encrypt data as a non-root user would be a significant advantage of the encryption in the filesystem technique.

Re:Uh, excuse me?

[Lethyos]

Is there a way to mount the loopback device as a non-root user under linux (and for that matter any of the bsds)

Although I do use GBDE on FreeBSD 5, I cannot say if you can grant users the rights to create encrypted block devices. It is possible under Linux, but only to a limited extent.

Users cannot safely create loopback devices using losetup without circumventing security measures (not desirable) but mount can. In /etc/fstab, create an entry (example: /dev/device mount point filesystem user,noauto,rw,loop,encryption=cypher,keybits=keys ize 0 0 ) which specifies all the relevant parameters, but also make sure that it is user mountable. The loopback device in this case is assigned automatically. (This, by the way, assumes you have the latest util-linux package. Pretty much any distro these days will suffice.) If that doesn't work, I may be missing a few details. I'm a little rusty on that, so you'll have to fill in the blanks (tomorrow I can look into this a little more closely and give a better answer if this doesn't lead you anywhere). As for doing this in a slightly more precise manner, I am not sure. Again, I'll do some research and see what I can come up with. In the meantime, this should be enough to get you started.

The down-side of this is there's a lot of debate over the architecture of loopback encryption. In particular how the keybits parameter is passed to the cypher. I do not quite understand the particulars of this debate (and nor can I, unfortunantly, supply you with links to the mailing list archives where I read about this in the first place) but it appears that things will be changing (for the better) once some politics are worked out. In the meantime, this solution seems pretty good.

Re:Uh, excuse me?

[Anonymous Coward]

Everything is written to the disk encrypted, including the file system itself and not just the data.

...which is a cryptographic weakness as filesystem metadata contains easily predictable regions that can be used to crack your keys.

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:This looks very cool.

[squidinkcalligraphy]

Now that I think about it, the main problem would be with programs knowing that files can also be accessed as directories. tar would work fine provided that the readdir() system call (or whatever you'd use to get a directory's contents) returns both a file and a directory for each file.

Re:This looks very cool.

[Skorgu]

I've given this some thought since I first read about Reiser4. I know very little about low-level systems programming, so I concede that my solution is certainly not the fastest way.

I think this is (wait for it) a perfect application for either XML or another, easily-parseable format.

Instead of trying to hack tar to handle metadata (which is not its purpose anyway, tools should have one task, right?), make a dedicated serialization app. Call it feather (pardon the pun) or something. All it does is take a file in whatever filesystem you're running, grab all the metadata and serialize it in a standardized way into XML or something (anything, I use XML as an example, not a recommendation), then tar that metadata up in a file. Then, on another system, you can run feather to unpack the tar and restore the metadata in whatever format the machine uses. This would allow for portable ACLs as well as a bunch of other nifty things.

Of course you could hack tar to do it, but I think it should be a separate app first, and just piped to tar like the -z and -j options are.

Just imagine it, you could tar and feather your documents directory, with its complicated ACLs and Nifty-keen reiser4 metadata, then unpack it on your Samba-controlled NT box and have it keep all the ACLs. The other stuff gets put into a .feather directory or something.

All that needs to be done is a namespace for the serialization. XML is easily parsed so userspace apps can handle it, and we don't really care about size as its all getting tbz2'd anyway.

Again, its not efficient or particularly pretty. But it is portable.

Re:This looks very cool.

[IamTheRealMike]

Yeah, i'd have to echo this sentiment. Tar is a legacy hangover, not something to be treasured and preserved. Technically the ZIP format used on Windows is far better, and to be frank I'd much rather see the Linux community move to using a simplified filing system that supports all the features we want mounted via the loopback device. ie, rather than "extract a tar.gz, edit the files, possibly recreate" you'd "mount the .box file, edit the files, unmount". GNOME and KDE could provide easy access to this so you could box/unbox anything. Meanwhile the on-disk format would be extensible.

MacOS already does something similar with DMG files, it might be worth moving in a similar direction.

Re:This looks very cool.

[dublin]

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.

Wow! I'm going to have to read up on this (yes I admit to not having read the article yet...)

If it really works that way, we may well be witnessing the dawning of a very interesting new age for tools like Blosxom, NoSQL, and Starbase that really leverage the filesystem to help provide structure... The fact that all of those tools are tiny and offer awesome leverage is directly related to the ways they leverage filesystems structures to replace much more cumbersome conventional methods...

Re:This looks very cool.

[squidinkcalligraphy]

I agree that tar has its problems, but I would have to disagree with zip being better. Better for what? tar + gz gives better compression that zip (bz2 even more so). The file format of tar will eventually need to be updated, but really, as an archiving format, it does the job - and keeps things small. Although I suppose disk space is cheap these days...

A disk image system would be nice; you can do this already using the loopback device, although the image file size is fixed to what ever you create it as.

Re:This looks very cool.

[IamTheRealMike]

Tar.gz gives better ratios only for certain types of data and you can achieve the same effect by creating "solid" zips (the reason they compress source code better is because tarballs are always solid). So I still think ZIP is more flexible, and can achieve better compression.

Re:Lindows

[Anonymous Coward]

I like how there's a big Lindows.com graphic link at the top of namesys.com. I guess they didn't get the memo about the name change.

dancing trees?

[wobblie]

but where are the dancing badgers? I want dancing badgers in my filesystem.

Re:dancing trees?

[mh101]

you mean like this? :)

Or the alternate response...

Badgers? Badgers!? We don't need no stinking badgers!

Interopability

[Anonymous Coward]

With so many filesystems around, it is strange that nobody is working on interopability. Till today no filesystem exists which works well both in windows and linux.

1. FAT - comes close but does not support very large paritions and files larger than 4GB
2. NTFS - Poor write support in linux
3. EXT2/3 - Writing hardly works in windows and does not support large files.
4. ResierFS/XFS - Have limited support in windows.

Any multi-OS file system out there?

Re:Interopability

[awehttam]

OS/2's HPFS? :)

Re:Interopability

[ahodgson]

Well, let's see. FAT and NTFS are owned by Microsoft, and they aren't sharing.

The others can't be added to Windows by anyone except Microsoft, cause no one else has the code. Oh, and Microsoft has zero reason to want to add them, because it would make it easier for people to have Windows and Linux co-exist.

Re:Interopability

[JohnGalt00]

Well, you know whom to blame.

At least you have SSH, FTP and Samba to share over a network.

Re:Interopability

[Anonymous Coward]

ISO-9660 maybe?

Re:Interopability

[Forbman]

Hmm... but you can get the Windows Driver Developer's Kit, because file systems are implemented at the driver level. Then, you would probably need to go back to old information about WinNT3.x, as well as 4.x.

It is probably possible to do with the information that MS has published over time.

Re:Interopability

[ardor]

Obviously, it is very difficult to add a new filesystem driver to Windows, since no specs are available.
But what about a virtual drive? Daemon Tools emulates a DVD-ROM drive. Why can't we use this concept to circumvent the need for a driver? Develop a Windows Service which creates a virtual drive, lets say Drive X. In the Service, I can map Drive X to Partition Y. Obviously, I/O would not be as fast as with a native driver, but it should work, shouldnt it?

Re:Interopability

[Air-conditioned cowh]

Well you can get ext2 drivers for Windows NT/2000XP. I'm sure the same principle could be used for other file systems.

Re:Interopability

[soulsteal]

What about FAT32 with VFAT for long filenames? Linux seems to handle that fine, as well as all flavors of Windows since Windows 95B.

Re:Interopability

[Proteus]

The others can't be added to Windows by anyone except Microsoft, cause no one else has the code. Oh, and Microsoft has zero reason to want to add them, because it would make it easier for people to have Windows and Linux co-exist.

What most people don't seem to get is that Microsoft's motivations are based in simple corporate economics.

MS Windows is competing with Linux. Why should they spend development dollars to support a "foreign" filesystem when they could spend the same money improving their product to beter compete?

MS isn't worried about how easy it is for Windows and Linux to co-exist. Read that sentence again. The reason why Windows and Linux do not always co-exist peacefully is precisely because MS doesn't care if Windows and Linux get along. They care that a Windows machine runs Windows in a reasonably sane manner. Windows is the dominant OS right now; why would they spend money making sure they can "play nice" with another OS? Linux "plays nice" with Windows because it needs to do so in order to gain a foothold in the Windows market-share.

Microsoft does not see any competitive advantage -- and, for what its worth, neither do I see any -- in marketing to anyone except those who use MS exclusively on a machine.

Re:Interopability

[balster neb]

Precisly this question was asked in an Ask Slashdot earlier this year.

Re:Interopability

[Anonymous Coward]

bzzt wrong.

The specs are available, search for "IFS", the downside is you need to sign an agreement and hand over $899.

Re:Interopability

[ahodgson]

The reason why Windows and Linux do not always co-exist peacefully is precisely because MS doesn't care if Windows and Linux get along.

I'm sorry, but you're wrong. Microsoft has very good reasons to deliberately make the two NOT work together, and they have demonstrated repeatedly through their history that they will do exactly that.

Look up the history of DR-DOS if you want reminders.

Re:Interopability

[Proteus]

Look up the history of DR-DOS if you want reminders.

I'm well aware of that history, but Linux as a dual-boot is targeted toward the desktop market. And, despite my personal, pro-Linux opinion on the matter, the fact remains that Linux is not going to compete with MS on the desktop for a long while.

DR-DOS, on the other hand, was successfully competing with MS-DOS. I don't put it past MS to break Linux compatibility by doing things like altering filesystems and making migration harder. But sabotaging dual-boot capability is likely not high on the list.

You know you're a geek when..

[mewphobia]

Seriously.... their server admins must be FSCKing angry.

You know you're a geek when you read that as "Seriously.... their server admins must be Filesystem-checking angry". I was trying to work out if they were angry for not having to FSCK their filesystems anymore or what? Doh.

Re:You know you're a geek when..

[lewp]

Actually, you know you're not a geek when you've never made the fsck/fuck connection before.

Why I use ext3 (Was Re:ext3 to reiser4)

[SealBeater]

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.

I have to take exception to this, as according to everything I know, this is a bit deceptive. As you would normally want to use a journaling
filesystem on very large discs (whether this be regular hard drives, which is bad enough, but can get very large when dealing with raid arrays, for
instance). This is the single most important factor when it came to deciding what filesystem to run, namely, can reiserfs 4 be upgraded to new
versions easily? In the past, the only way to upgrade rieiserfs was to reformat the device. This is a point that I don't think people pay enough
attention to, especially in production enviroments. Say I have a 500 Gig raid array. I use reiserfs, (which is an excellent filesystem) and it is
later discovered to have a security flaw or a bug that causes data corruption. In order to upgrade to a new version of reiserfs, you have to
reformat the entire array. With ext3, you unmount the device, mount it as ext2, unmount it and remount it as ext3. Done. This is hugely important.
I am completely uninterested in having to maintain a 1Tb of drive space, in order to upgrade a 500G array.
Well, that wouldn't happen, you say? It did. Google
Also, I do seem to remember some problems running LVM and NFS on reiserfs as well, but I am willing to be corrected.

SealBeater

P.S. I am only really interested in knowing if I can upgrade a reiserfs filesystem without having to reformat.

Re:Why I use ext3 (Was Re:ext3 to reiser4)

[Aardpig]

This is the single most important factor when it came to deciding what filesystem to run, namely, can reiserfs 4 be upgraded to new versions easily?

Yes; as I understand it, ReiserFS 4 is designed with a plug-in architecture, so that future improvements to the filesystem can be incorporated in a non-destructive manner. You can read more about this functionality in the summary of the new features in v.4.

Re:Why I use ext3 (Was Re:ext3 to reiser4)

[mindstrm]

The situation you ahve with ext2 to ext3 is unique, and not indicative of normal filesystem decisions during administration.

If you have a large filesystem with important data, you choose a system that meets your needs, and generally stick with it unless you need to upgrade.

The appeal of ext3 IS that you can seamlessly go back and forth to ext2 without any real structural change to the FS.... sure... but that's unique.

You don't just convert your array to XFS to Reiser, etc.... you decide what meets your needs and use that.

IT's not feasible to keep all filesystems compatable so upgrades don't require reformatting, unless you are talking about small changes, or speed penalties.

Re:Why I use ext3 (Was Re:ext3 to reiser4)

[lucas teh geek]

Hint for the future: dont include
at the end of every line, not everyone views /. at the same resolution as you and anyway, line wrapping is automatic.

Re:Why I use ext3 (Was Re:ext3 to reiser4)

[Anonymous Coward]

Interesting.
Google gives one hundred more hits for the same search with ext3.
http://www.google.com/search?num=50&hl=en&lr=&ie=U TF-8&q=ext3+corruption

Oh, and don't change the device while imaging.

[Lethyos]

It should be noted that the device to image should not have any filesystems mounted in a writable or otherwise modifiable state when reading the image. This, of course, would apply to Ghost too if it could run within an multi-user operating system, but that's not the point. If the operating system is performing write operations on the device being imaged, those writes can be reflected in an incomplete state within the disk image, meaning that the disk image is either corrupt or does not fully represent the state of the device at the time of the imaging. If you are booting the system with something like Knoppix to do the imaging, chances are no filesystems on the device will be mounted (which is good). If you do mount them, be sure to specify the ro option (example: mount /dev/hda1 /mnt -o ro ).

Re:Oh, and don't change the device while imaging.

[Anonymous Coward]

Fortunately, LVM supports the concept of 'snapshots': Forking a logical volume so that you can use it normally in your production environment, and have a second copy that wont change until you release it (or you run out of space on the snapshot logical volume). commands are: lvcreate -L[size] -s -n [name] [block/device/path]. A URL for LVM snapshots is http://tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.h tml. I use Reiser4 and LVM2 on a testbox/workbox and it's been doing great.

OT: Your Sig

[einhverfr]

If you try to fail and succeed, which have you done? - Uli's moose

Misunderestimated yourself?

Does that mean that when someone misunderestimates Bush, he tries to underestimate him and fails?

Re:OT: Your Sig

[GreyWolf3000]

Funny--'misunderestimate' seems like a word Bush would use.

I don't know how it's funny. It just is.

Re:OT: Your Sig

[mattgorle]

Seems young George is a constant source of amusement (and frustration) to many of us.

In much the same way as John Prescott is over here (in the UK).

Some choice quotes:

• "I would like to make some start in my speech."
• "The city of York already is a city, as is my own city of Hull is a city, and that I think is the definition of city and town."
• "If I decide it is right to make a statement to this house, that's what I do, that's what I have done, and it didn't come from anybody else."
• "At the end of the day it's a negotiated settlement, they're always the more difficult ways of finding acts of violence or unilateral actions like this will not help, and we just see the matter escalating from day to day, again just walk the table - that's still the only solution!"

More here and here.

If education has gone downhill since he was a lad, we're all in trouble!

Re:OT: Your Sig

[einhverfr]

Funny--'misunderestimate' seems like a word Bush would use.

He actually did use that, saying people had misunderestimated him. I was just thinking that it must be impossible to underestimate him....

You forgot about a huge plus when using crypto...

[Anonymous Coward]

"Plausible deniability."

Lets say you were being a civil disobedient little Slashbot and were storing tons of fair-use copied MP3s, DiVX-encoded movies, or whatever. When the feds come and unplug your boxen and the disks go cold, you can actually claim that you have A) no idea what is on the disks and B) you have no idea what the symmetric key to decrypt is (thanks to the US Constitution). And if you're using a suitably strong cypher, you've got at least a few decades on your side (by then, the statute of limitations expires for your case).

Of course, if you're so much of an idiot that your own crypto is going to block your access to your data... well, there's not much hope for you. The same could be said about dopes who put door locks on their homes then flush their keys down toilets.

time till vanilla kernel

[OmniVector]

is there any time frame on how long it will take to be in the vanilla kernel? how about gentoo-dev-sources? I'd like to check it out, but i hate fooling with kernel patches.

Re:time till vanilla kernel

[Simonics Zsolt]

It's in the Andrew Morton kernels from 2.6.8.1-mm2 (mm-sources on gentoo)

MOD PARENT DOWN TO +1, FUNNY

[Anonymous Coward]

LiViNg In A wOrLd Of MaKe-BeLiEvE yOu ArE!!! OMGWTFBBQ!!! LOLZ!!!

MOD PARENT UP TO -1, STUPID

[Anonymous Coward]

whoa, czech it, jc 'nho, so wtf, ok? whatever lubb

Old benchmarks?

[G3ckoG33k]

Did I miss something or aren't those benchmarks rather old by now? The most recent is from March, this year. The rest from 2003...

# 2004.03.26 slow.c comparison against ext2, ext3
# 2003.11.20 mongo comparison against ext3
# Bonnie++ comparison of reiser4 and ext3 done at 2003.09.30.
# 2003.09.25 mongo comparison against ext3
# 2003.08.28 mongo comparison against ext3
# 2003.08.27 mongo comparison against ext3
# 2003.08.26 mongo comparison against ext3
# 2003.08.18 mongo comparison against ext3
# 2003.08.12 mongo comparison against ext3

As retrieved from here.

Surely both ext3 and Reiser 4 must have evolved since then.

EXT2IFS is a start in that direction...

[Nick Driver]

There is a Windows "Installable File System" for accessing ext2/ext3 partitions in read-only mode. See this website for EXT2IFS

if you troll it they will cum

[Anonymous Coward]

theirs a ton of stupid ppl posting in this thread now

makes sense for the stupid parent post :)

Benchmarks...

[IpSo_]

Benchmark comparing virtually every major file system against each other. They are fairly old, but I doubt things have changed significantly since they were run.

fsbench.netnation.com

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: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.

Re:Filesystems seem to be like VWs

[asuffield]

> I've found Ext3 to be slow when you have more than about 5000 files in a directory.

Use a 2.6 kernel and dir_index.

Re:Filesystems seem to be like VWs

[Daniel Phillips]

I've found Ext3 to be slow when you have more than about 5000 files in a directory.

Now that Ext3 has the HTree directory index patch, that should no longer be the case.

Re:Filesystems seem to be like VWs

[JamieF]

ReiserFS is stunningly fast, and efficiently stores small files. That's why I use it. It's not much harder to type "mkfs.reiserfs" than "mkfs.ext3" or whatever.

I'm aware that disk space is cheap vs. sysadmin time, but it really is trivial to use ReiserFS, and (especially on Unix) the prospect of having a major space *and performance* saving from just using a different filesystem is very appealing.

If your distro doesn't provide ReiserFS, on the other hand, then maybe you should ask yourself why you're using that distro.

Reasons to stick with ext3:

[Anonymous Coward]

Reiser can't badblocks.

Not fair need to use notail

[just someone]

Not sure, but that might make it 125k files pointing to one block, since reiserfs stuff files in a block until it's full.
Would be space efficient.

I gave reiser a boot in the a$$ right out the door

[ZeekWatson]

I feel for you man. I had 3 different installations with Reiser3 corrupt on me. Turns out reiserfs is a POS.

On reliability:
"After 3 or 4 power cycles, ReiserFS became corrupted to the point that the system would not boot up (the fsck failed and the bootup stopped there)." - http://www.redhat.com/archives/fedora-list/2004-Ju ly/msg00418.html

On code maturity:
"In contrast, ReiserFS' fsck is in its infancy..." - http://www-106.ibm.com/developerworks/linux/librar y/l-fs7/

Hans and co's attitude:
"For $25 you get an answer to any question we can answer with less than half an hour of working on it. fsck support sometimes takes more than half an hour" - http://www.namesys.com/support.html

Will Red Hat . . ?

[Anonymous Coward]

Now that ReiserFS4 makes ext3 look like a turd in a punch bowl, will Red Hat enable ReiserFS for the root partition in the Anaconda installer instead of making us use the "secret word"? Probably not since no ReiserFS employees work at Red Hat.

cd into files for attributes.. neat...

[otis wildflower]

.. I'd been wondering if that were supportable in Linux.. And atomic file changes are neat, though I still think building a DB filesystem would allow for more flexibility in stuff like file searching, typing, attributes, and all the stuff you can build into a database like snapshots, clustering, etc..

Re:here is the text from namesys.com

[poptones]

I'm STILL (re)learning my way around the command line in linux and only recently had the courage to completely remove windows from my machine - but even I have been able to "easily" add an encrypted home directory to my machine. In fact, I encrypt /var and /tmp and /usr, too - and its almost entirely done using the Mandrake install wizard (although it likely works with Suse too). There's bugs in there that had to be figured out and the wizard tells you it can't do things you have to learn to do - but I did it without even knowing (at the beginning) how fstab worked or what a modprobe was. Admittedly it took a few weeks and what seems like hundreds of reinstallations (mostly because I didn't know how to repair a botched job) to figure it out, but once learned it ain't hard to do. And just to save others from having to do "hundreds of reinstalls" I even made a quickie HOWTO and posted it to alt.os.inux.mandrake.

Now I have added scripts to my system that give me all the point and shoot functionality of pgpdisk in windows. All it took was a bit of time to learn the tools (mountloop, mount, umount, etc) and a hack of a shell script I found online and now opening an encrypted filesystem is as easy as clicking it, typing the pass, and pressing enter.

What makes the present system great is its level of abstraction. Having a "thing" one can move around to ANY media without having to create new tools every time is a thing of beauty. It takes a tweaky (and now proprietary) add-on to do this in windows - sticking all the encryption in the fs itself would just be a step back to doing things the Redmond way.

Re:I gave reiser a boot in the a$$ right out the d

[Anonymous Coward]

On code maturity: "In contrast, ReiserFS' fsck is in its infancy..." - http://www-106.ibm.com/developerworks/linux/librar y/l-fs7/

Note the begining of that article: With the 2.4 release of Linux come a host of new filesystem possibilities, including Reiserfs, XFS, GFS, and others.

Also the date: 1 November 2001

User quotas without patching kernel?

[Anonymous Coward]

I read the article and the site pages (not the first time, I like reading manifestos ;0) but I'm still not sure if I'll get user quotas without patching the kernel.

I just installed sarge via Mepis (using a really small drive, so I only used a small boot partition, a small swap space, and a single partition for everything else), and one of the questions when I used ReiserFS for the partions was something about needing the 2.6 kernel for something. This is the first time I saw I had the options for notail and a few other options that I haven't seen before. More options than previously. Using the 2.4.26 iirc kernel. So there is some new stuff in the latest 2.4.x kernel, or Mepis gives more options compared to other distros (older versions of Suse/Red Hat/Knoppix/Slackware) that I'm used to, though Suse's installer (back at 8.0 and earlier versions) did give a little more control with options on ReiserFS partitions.

iirc, one of the questions during the setup a few days ago did have to do with user quotas, telling me that I needed to select an ext partition if I wanted user quotas (instead of ReiserFS, not Reiser4).

So with Reiser4, is one getting user quotas without patching the kernel?

If this is true, I'll be moving to the the 2.6.x kernel sooner than I thought. The 2.4 kernel has plenty of life left in it, and according to Linus himself, the 2.4 kernel is faster in some circumstances, tradeoffs had to be made when designing the 2.6 kernel. But quotas is enough to push me to 2.6

Quota Support

[rf0]

As far as I can see there is still no mainline quota support. Does anyone know differently?

Rus

RTFA and the LINKS too?

[adamscottphotos]

"Namesys seeks to raise the dead, and is willing to commit whatever unholy acts that requires."

Straight from the horses mouth - on their Visions of the Future page, which was directly linked from the main document. I'm sure you all read the links too, right? :)

He sure does seem to be on the defensive - maybe time to get out and get some fresh air, take the tinfoil hat off for a bit...

Re:RTFA and the LINKS too?

[Anonymous Coward]

It's not what you think it is. Its good they re-designed FS from scratch so it is really fast. I thanks them a lot for that.

Its also true that programmer's dont want to touch old code....

Are there any non MS filesystem drivers anywhere

[Anonymous Coward]

iso9660 ?

Re:cd into files for attributes.. neat...

[Forbman]

Well, I bet you can't wait for WinFS. Oracle, of course, has iFS kind of skulking around, too.

Maybe making the filesystem database work more like a relational database is what you really meant.

Three things came out of Berkeley...

[loonicks]

Good to hear the Linux filesystem envelope is being pushed further. The illustrations make me wonder if LSD had anything to do with Reiser4, but... whatever helps, I suppose.

It's important only

[warrax_666]

if you can intentionally cause collisions by modifying messages appropriately. Then the hash becomes useless for verifying message integrity (because someone could have modified the message while keeping the hash identical).

Reiser4 still slow?

[calc]

The latest benchmark mongo benchmark from 2003.11.20 on the namesys site shows Reiser4 still being quite slow as far as CPU_TIME goes. Hopefully this has improved in the past year, it was up to 5 times slower than ext3 at some operations. If you look at REAL_TIME it is faster but that just means you are using 5x the CPU power to do the same things. That 5x CPU could be better used for serving data, multimedia editing, etc.

Does anyone know if there are more recent mongo benchmarks of the Reiser4 code?

http://namesys.com/benchmarks.html#mongo.2003.11 .2 0

Re:Reiser4 still slow?

[Anonymous Coward]

It is generally accepted that disk IO is the greatest bottleneck in any system and the gap is growing. That is, CPU speeds are increasing at rates much faster than disk speeds. Therefore a compromise for less disk IO time at the expense of more CPU time may not be a bad thing.

Your example of multimedia editing is a perfect example where the compromise may actually result in better performance. Highly disk IO intensive, less demanding on the processor. Serving data, in particular many small files (like email), is an almost entirely disk bound operation thus it may result in better performance under ResierFS.

AWESOME

[Anonymous Coward]

Awesome! I love being the first guy to test out a filesystem!

I'll let you guys know if it works!

<zaps all data>

Re:here is the text from namesys.com

[hansreiser]

The gentoo guys have not complained about my characterization, if they do in an email I will change it. As the other poster said, gentoo seems to prefer reiserfs in what they write and say.

Hans

Atomic, journalled, log-structured.

[0x0d0a]

Close. I will confess that I don't know *exactly* the precise definition of journalled -- I believe that roughly it's "write out each operation guaranteed to be atomic to the disk before that operation is committed"

Atomicity is not an alternative to journalling. Journalling is a mechanism often used to provide atomicity. Atomicity simply means that a change is either entirely committed to disk, or not committed to disk. There can be atomicity at various levels -- database transactions are also atomic, for instance, as is each operation on filesystem metadata in ext3 (which simply means that the filesystem metadata will not become corrupt on power loss).

An example of the difference between atomicity provided via journalling and atomicity provided without journalling -- if a filesystem recieved a write of 20 bytes to the end of a file, a write that fit within a block, it could simply read the contents of the existing block on the hard drive, and then write the modified block back, since block-level writes are guaranteed to be atomic on hard drives (assuming, of course, that the filesystem stores the associated length data in the block). This would not be journalled, because the change is never written to a separate location, but it *would* be atomic, since the filesystem is never in an inconsistent state -- either the change is written or it is not written.

There is also a mechanism similar to journalling (though different) called logging -- there are "log-structured filesystems". I am not familiar with the difference between journalling and logging. Just guessing from distributed systems knowledge, it's likely that logging means that every operation is written to a log in order, and that a filesystem's state can be reproduced by playing back the log.

Bad blocks, etc.

[warrax_666]

(We didn't consider reiserfs because of its lack of bad block handling).

Oh, dear. Bad block handling is not needed on modern drives, all moderns drives have automatic remapping of failing blocks, and if you have a drive which actually has bad blocks which are visible to the OS you should not be storing any data on that drive.

Just to add a data point: I've also had very mixed experiences with XFS. I installed it and it seemed to be chugging along fine for ~1 year (just regular desktop machine, no particular I/O load to speak of) until suddenly the initial root mount showed an empty /. I was never able to track the cause down, but I promptly changed to ReiserFS and haven't looked back since.

Re:Bad blocks, etc.

[Anonymous Coward]

Oh, dear. Bad block handling is not needed on modern drives

Spoken by someone who's never had a drive develop bad blocks.

Re:Bad blocks, etc.

[Anonymous Coward]

If you continue reading the post, I think it's clear that he meant to say:

Oh, dear. Bad block handling is not needed on modern file systems

He says how it is used silently by hard drives, and the OS shouldn't know about it.

Re:Bad blocks, etc.

[drinkypoo]

Oh, dear. Bad block handling is not needed on modern drives, all moderns drives have automatic remapping of failing blocks, and if you have a drive which actually has bad blocks which are visible to the OS you should not be storing any data on that drive.

I have encountered several situations in which the hard drive did not properly handle a bad block. Also, sometimes you don't have a choice about where to store data, at least for a few days and until you can get a replacement.

I'm a fan

[stone22]

After a harddisk crashed in my raid while it was restoring from a previous crashed disk. Not only did it keep on syncronizing, be it with al lot of "relocating block x to x" errors, it also was completely fixed by reiserfsck afterwards.

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:Windows vs Linux: encrypted filesystems

[Dogers]

how much to put in my ~/main/notes/passwords directory

ahh, the virtual post-it note lives on i see! :)

Re:Windows vs Linux: encrypted filesystems

[cortana]

Neither can filesystem-level encryption replace block-level encryption. Encryption performed at different levels can be useful for different tasks--the two do not need to be mutually exclusive.

Think of it as the comparison between using 802.1x vs IPSec vs TLS vs PGP. Different layers to serve different purposes. :)

Re:Windows vs Linux: encrypted filesystems

[Anonymous Coward]

And you remember your 100's of web-board, Slashdot account, newegg account, style passwords? Or maybe you just use the same password for everything?

pffft, you have to write them down somewhere. Encrypting them is a nice preventative measure.

Re:Windows vs Linux: encrypted filesystems

[WuphonsReach]

And you remember your 100's of web-board, Slashdot account, newegg account, style passwords? Or maybe you just use the same password for everything?

I simply keep mine in plain text files with the contents encrypted using GPGShell (encrypt current window).

Same end result. I used to keep them in an encrypted volume, but since that volume was always mounted, they were an easy target for a worm.

Re: Without pluggins we will drown !!

[bodgit]

http://namesys.com/r4pics/withoutpluginsJ.jpg

Surely with no pluggin, the water goes down the plugghole?

Re:I gave reiser a boot in the a$$ right out the d

[Anonymous Coward]

Losing one installation is "ah well", losing two is "bad luck", losing three is "sheer stupidity on your part for staying with a filesystem you found unreliable".

FUD alert!

[Anonymous Coward]

FFS' softupdates provide more than just metadata journaling

On the other hand ...

[Pegasus]

If you had to deliver millions of email messages per day, you'd find out that ext3 is not the tool for the job. I simply can't imagine email servers on this scale without reiserfs.

Also, i lost my /home three times last year on ext3. The cause was a hardware problem, true, but fs should not be a toast because of it.

YMMV.

Re:On the other hand ...

[martinde]

> The cause was a hardware problem, true, but fs should not be a toast because of it.

When you develop software that is immune to hardware failure, be sure to let us all know ;-)

How about a undo or at least a trashcan/undelete?

[grumbel]

One of the things I still miss most under Linux are a proper trashcan/undelete (at filesystem level, not at GUI level that doesn't help on the shell) or even better a full blown 'undo' operation on the filesystem. Even MSDOS provided a very basic undelete operation and I can't really believe that we are still without it on Linux.

Does ReiserFSv4 provide stuff like that? Or in case it don't, are the 'Plugins' that it supports
powerfull enough for that and are there maybe already plugins awailable that add an undelete/undo? Better yet would of course be a fullblown versioned filesystem, how about that, is that doable with ReiserFSv4 plugins?

And how do the plugins relate to for example GNU Hurds translators or LUFS? Do they act at a similar level, or are they completly different?

Speaking of JFS...

[ttldkns]

where are the comparisons of this FS to JFS and even XFS? there was a file system comparison on ./ a while ago now (cant remember) and i seem to remember XFS beating the old reiserfs by a bit and it also showed how reiserfs used the most CPU for read/write. For my server i chose JFS as it was faster than EXT3 and used the least CPU.

There have been faster file systems than EXT3 for a while now, i dont know why distros havent switched over to them.

Re:Speaking of JFS...

[Erwos]

"There have been faster file systems than EXT3 for a while now, i dont know why distros havent switched over to them."

Easy answer: speed isn't everything. Ext3 has the advantage that it's readable almost everywhere (since ext2 support is common) if you get into trouble. It's also extremely reliable and well-tested, and it's not all that slow, either. Most benchmarks I've seen put it in the upper end of the pack.

-Erwos

Re:Speaking of JFS...

[Trashman]

There have been faster file systems than EXT3 for a while now, i dont know why distros havent switched over to them.

Because they:

a. either aren't as reliable or,
b. have some inherent issues that prevent widespread adoption.

As for myself, I have been burned by reiser so I don't use it. If it works for you, then great. I've had no issues (in recent memory) with ext3.

[reiserfs4+]: it's just Unix

[Anonymous Coward]

---

In my ignorance I thought Unix fs should remain more or less the same.

Then I read the introductory page on reiser4 at http://www.namesys.com/v4/v4.html, and look, here are people that know how to make Unix more Unix.

I think, that is the right direction, and the elegance and semplicity of the ideas described makes it self evident.

Reiser blew it with me.

[rew]

I've encountered a few things with respect to ReiserFS:

• I get to upgrade my filesystem so that I don't get to downgrade my kernel should I run into trouble.
• Whenever something doesn't work right, (which never happened to me on Ext2), Hans Reiser tells me that "it's fixed in the newest version", and I get to upgrade my kernel and on-disk-format without the possiblity to back out.
• When things DO go wrong, (which never happend to me on ext2/ext3), it seems I need to tell reiserfsck which sub-version of the filesystem is on my disk (Hans knows that very well on his disks, but I just use filesystems to store my files). Otherwise reiser-fsck may make a bigger mess than it started with.
• When reiser-fsck is neccesary, it often requires a "rebuild-tree", which is time-consuming.
• My filesystem was "suspect". So I start reiserfsck. It apparently does nothing, as it's done in 2 seconds (which is unlikely on a 640Gb partition) When reiser-fsck --rebuild-tree is started it informs me that it's going to take some 5 hours to complete. As I didn't have that time, I interrupt it. Filesystem gone. Apparently the first thing it does is invalidate the old structures. Now instead of "suspect" I don't have a filesystem at all, and have to sit out the 5 hours for which I don't have the time....
• I sometimes have a disk-image of a different filesystem on my disk in a file. Hans Reiser tells me that a rebuild-tree would link the files inside the image into my filesytem! Fixed in newest version. Phew.

Too many (serious) problems, that I'm not ever going to try Reiserfs again. Sorry.

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.

I WOULDN'T recommend it -- untested

[Anonymous Coward]

Reiser4 has ONLY been tested on x86 so far. Which, for me, puts it right up there with WINE as a viable solution for Linux computing issues.

I'm using Reiser3/2.6.8 on PPC right now, but I'm noticing weird issues with it still. God knows what Reiser4 would do.

Let me know when it's been tested enough to DESERVE release :/

Re:atomic - free fpace?

[jwdb]

What does this atomic structure mean for the stability of the system in the case where there is not enough space to write the new tree? Say you write a file 4 directories deep, but your disk is so full (or so small) that you only have space for 3 more directory records? Would you simply get an out of space error?

How about editing a file? If you change text in the middle, is just the middle copied and written back? Everything after the middle? Everything? Again the issue of space...

I'm asking here because the site is slow as molasses, and I don't know if it even answers these questions...

Jw

No thanx : )

[essreenim]

Why would you want to? Dont be fooled. Of course they are going to blow their own trumpet
We must caution that just as Linux 2.6 is not yet as stable as Linux 2.4, it will also be some substantial time before V4 is as stable as V3.
My machine is built for stability. I use only what I think/hope of as stable hardware components on Slackware 10 - the most stable OS using kernel 2.4.26 - arguably one of the most stable kernels. And I use the excellent, reliable ext2 fs.

Rescue tools

[Anonymous Coward]

I doubt if you'll find any tools for it on common rescue disks. That was already a disadvantage of earlier versions.

Scenario: you need to edit fstab but you can't access your Reiser partition. :(

Strange Linux Math

[rudy_wayne]

from the download page:
"Don't use linux kernel 2.4.16 or earlier for reiserfs operations .... 2.4.16, 2.4.9, and 2.4.3 are especially bad. .... 2.4.24 is the latest release at the time of writing ...."

2.4.24 is newer than 2.4.3 and 2.4.9 ??

Re:Strange Linux Math

[Anonymous Coward]

Yes, because 24 is a bigger number than 9. See how that works?

Re:Strange Linux Math

[Anonymous Coward]

24 > 9 > 3; so yes, 2.4.24 is newer than 2.4.3 and 2.4.9

Re:Strange Linux Math

[Anonymous Coward]

Uh, yeah.
2.4.3 ~= 2.4.03
2.4.3 2.4.24 2.4.30

Re:Strange Linux Math

[Junta]

How is that strange? 24>3 and 24>9 is strange to you?

Re:Strange Linux Math

[rudy_wayne]

2.4.16
2.4.24
2.4.30
2.4.90

That's how I learned to count. So let me get this straight:

2.4.3 is not another way of saying 2.4.30 ?

Re:Strange Linux Math

[TeknoHog]

2.4.3 is not another way of saying 2.4.30 ?

It's not. There are two decimal points so it cannot be a decimal number.

Linux and many other software projects use a set of integers for version numbering. So, for example, after 2.4.99 comes 2.4.100 because 99 and 100 are consecutive integers.

Re:Strange Linux Math

[Anonymous Coward]

Shut up.

Re:Strange Linux Math

[be-fan]

2.4.16
2.4.24
2.4.30
2.4.90

That's how I learned to count. So let me get this straight:

1) A period is not necessarily the decimal marker. In French, '.' is the triples marker (100.000 = one hundred thousand), and ',' is the decimal marker.

2) What moron teacher did you have that showed you numbers with more than one decimal point???

Great ! When will ti be in vanilla kernel ?

[Brane2]

Furthermore, when will it work on Opteron ?

I have tried to patch a kernel with this for a bazillion times, always with explosive result...

Data corruptions?

[Anonymous Coward]

I've seen studies saying that ReiserFS is the fastest FS ever, others say it only fast in the beggining then it slows down a lot when used (due to the trees becoming unbalanced or whatever), yet others say there's not much of a difference in terms of performance between ReiserFS and ext3.

One thing is certain though, there's a lot more people claiming data corruption with ReiserFS than with ext3.

Sounds cool!

[sproketboy]

Can I download it for Windows? :)

Two much feature makes for suboptimal system.

[Anonymous Coward]

So, R4 does safe writes.
This is important in transaction processing but for
most applications, knowing a write didn't complete is good enough.
I say, toss out the safe writes and let some hardware(Sun used NVRAM card to speed up writes and had safe write on by default) take care of it, if required by the application. Just work on the indexing and fsck speeds.
As for the comments on SGI's filesystem, it's slow as molasses if safe writing is turned on (default is off).
The above and $4 might get you a coffee at starbucks, but you'll still pay extra for net access.

What, no screenshots?

[Oestergaard]

What?!?

Come on Hans, give us what you know we slashdot junkies want!

How are we supposed to take a filesystem serious if there are no screenshots!?

8)

Q:ext3 to reiser4 ? A: Buy a cheap harddrive.

[OrangeTide]

Spend $120 on a new 200Gb harddrive and fill out the rebate form and get $60 of it back in 8 weeks or whatever. Then format the new harddrive as reiser4 and copy all the old data off your ext3 onto the new drive. Then come up with something to use that old 10Gb drive of yours for.

This is the easiest solution, but if you really don't have any money to spend on your Linux box then you're probably fine with ext3. Converting in-place is a fairly difficult piece of software to write (actually it's a difficult piece of software to prove that it works reliably. nobody wants their data to be trashed).

This just bit me in the a**

[hummassa]

One year and a half ago, I spent a lot of monies in a *huge* HD, and I have being using it happily ever after... until yesterday, when some bad blocks emerged. If I was using ext[23], I would fsck -b and continue to use the thing for one more year (warranty expired 6 mo ago). Now, I will have to take more "radical" measures... like fdisking "around" it or something...

@Aardpig, your sig is racist & inflammatory...

[irf]

@Aardpig, your sig is racist & inflammatory... Slashdot: where racism against Indians is OK... are you purporting that slashdot and it's readers are racists? and no offense, whatever your race is, that is fine with me, afterall we are all sprung from the same stock, sharers in the same hopes, and partakers of the same nature, but, i do find your signature rather racist, and inflammatory... peace to you and everyone

German magazine iX

[MemoryDragon]

Ran a huge article on Reiser4 a while ago. (Around 2 issues ago)
They said it was blazingly fast, but had problems, that the performance went down the drain once the processor did something not reiserfs related, thus IO is a higher burden on the processor, due to the tree structure they use.

The other problem is fragmentation, which should be resolved by a defrag daemon/tool running in the background, which was not available back then.

So my question, have those two problems been resolved already?

Don't forget FFS and soft updates

[Anonymous Coward]

Why leave the BSDs out of the pointless debates based on random observations.

<flame bait>
Soft updates beat journaling. There, I said it.
</flaim bait>

On the speed of disks

[bartc]

In light of the Reiser4 release, Tim Bray makes an interesting observation that, while the performance of CPUs has increased by a factor of 645 in the last 14 years, the speed of disk seeks has only increased by a factor of 3 to 4.

Copyright assignment

[Kaseijin]

Reiser FS is open source, so it is possible that others outside of Namesys have contributed as well.

Namesys requires contributors to stipulate that their work was made for hire and that Hans Reiser holds all rights to it.

Anyone had luck with convertfs?

[jayrcee]

I was wondering if anyone has any experience using this convertfs toolset.

This simple toolset allows you to change type of file system in the lack of backup space. The idea is to use sparse files support of primary filesystem. We create a sparse image of block device, mkfs secondary filesystem on it, mount it, mv files from primary filesystem to mounted image and then map image to the device. Remapping utility uses some kind of journaling to avoid breakage in case of power failure. It's expected that you have linux 2.4, glibc 2.2, recent util-linux, fileutils.

You can convert from virtually any filesystem type to virtually any one as long as they are both block-oriented and supported by Linux for read/write, and as long as primary filesystem supports sparse files.

Re:Your .sig

[Aardpig]

Be honest, how close am I?

Way off. I don't have a problem with people griping about losing their jobs -- that's human nature. I do, however, have a problem when this griping becomes the gross, slanderous, racist mischaracterization of the inhabitants of the Indian subcontinent.

Small files. Many files. Big files.

[pdc]

I think you have hit the nail on the head -- Unix programmers have assimilated a set of assumptions about file usage that reiserfs makes obsolete. Without those restrictions, "typical usage" might well change over time in interesting ways.

AC

[Luyseyal]

You saw Anonymous Coward at OLS? SWEET! That dude posts like MAD around here!

-l

Hashing and CRC

[NoMercy]

Yes ever hashing system has collisions, but really to check two files are the same which might have been corrupted naturally, use CRC, MD5 and other secure hashing alogrythums are just better against inteligent tampering. CRC's will catch an insanely large percentage of random data corruption and is faster than pretty much anything else, MD5's and SHA's are slower but much harder to fake.

Re: undo/undelete/trashcan

[Bisqwit]

If you are worried about your untrustability in deciding what to delete, just replace your rm binary with (or alias your rm command as) a program/script that moves the files to a dedicated trashcan directory.
This won't prevent other programs deleting files permanently, but I think neither does Windows.

Plugins == VMS fs?

[wandazulu]

So with a plugin, could you make a Reiser4 fs work like VMS' file system (i.e. foo.c;1, foo.c;2, etc.)? To me this is the holy grail of file systems...built in versioning by the file system itself, not a 3rd-party app like CVS.

Re:Your .sig

[irf]

hey Aardpig, don't you get it??
ok, i'll use your own words, YOUR SIGNATURE IS A GROSS, SLANDEROUS,
RACIST MISCHARACTERIZATION OF THE IN INHABITANTS OF planet earth,
save for THE IDIAN SUBCONTINENT.

Resize Goof

[Mark_MF-WN]

I was able to use reisersfsck to repair a partition resize that had gone wrong. I was pretty impressed -- only three files lost out of 20,000 (and fortunately they weren't important files!)

So I'd say it works pretty well.

Wandering logs, dancing trees..

[3.5 stripes]

Is this a file system or a disney cartoon?

Re:Your .sig

[Aardpig]

hey Aardpig, don't you get it??

No, apparently you don't. By your argument, the NAACP would be a racist organization.

ok, i'll use your own words, YOUR SIGNATURE IS A GROSS, SLANDEROUS, RACIST MISCHARACTERIZATION OF THE IN INHABITANTS OF planet earth, save for THE IDIAN SUBCONTINENT.

The first-grade errors in your post aptly characterize your inability to conduct a reasoned argument.

Re:Moron

[Anonymous Coward]

I can't believe this is modded down. Funny stuff.

Re:How about a undo or at least a trashcan/undelet

[Anonymous Coward]

Trashcan capability is something that should happen at the userland or window manager level. What you are asking for is the filesystem to read your mind. How is the filesystem supposed to know the difference between randomly generated temp files, and user files. You would end up with the file system spinning its wheels tracking stuff which will never be undeleted. Even the MSDOS undelete only worked provided that you didn't overwrite the data with something else (if I recall correctly). In the end I think we would be better served by a smarter 'rm' and a better GUI trash can (not the cheap hack the KDE team came up with).

Reiserfs3 - Reiserfs 4 conversion with RAID

[chathamhouse]

You could "upgrade" a reiser3 FS to a reiser4 FS if the partition was software raid-1.

I've done ext2 -> reiser3, and ext2->XFS with this before on production servers.

See the software RAID howto for specifics, but:

1) unmount, stop and split the mirror
2) mkfs.reiserfs4 one half of the mirror
3) mount the new and old halves of the mirror, and copy data from the old half to the new half
[ cd /olddir; find . -xdev | cpio -pdmu /newdir ]
4) rebuild the mirror using the new half as a source, attaching the old half once created.

Of course, it's probably less work to just back the disk up and blast it. Although it could save you time wirh boot disks, and unmountable partitions. Heck, you wouldn't do this without a backup anyways, right?

Re:I gave reiser a boot in the a$$ right out the d

[metamatic]

Ever notice that all the reports of ReiserFS corruption seem to be from RedHat users?

This should tell you something.

Shouldn’t we just go for an RDBMS?

[leandrod]

When I read Namesys' papers some time ago, it struck me that they seemed to aim to integrate a simple hierarchical DBMS at the kernel disguised as a filesystem.

Now if that's correct, we should instead just go for a much simpler, better-performing RDBMS.

none do this anymore

[Anonymous Coward]

The first UPSes that didn't have the charger running all the time appeared in the early 80s. They were actually called rapid standby systems at the time.

20 years later, there are no charger->battery->inverter systems left. They are very inefficient (meaning run hot) and are rather loud. People simply wouldn't use them if they were available.

A switchover type UPS will switch over to UPS power when the line power is bad. On a good one, you can say that 5% over is bad and make it switch. If it lasts more then the life of your battery, you're in trouble though.

Anyway, +/- 10% is NOTHING to your computer. They use switching power supplies. Switching power supplies adjust for input voltage. If you have an international power supply it can tolerate down to 90V and up to 240V with no ill effects. Even if you have a 120V only supply, it can still tolerate over 140V and down to 90V with no ill effects.

So, forget your +/- 10% stuff. It might matter on your stereo system, but not on your computer.

Re:none do this anymore

[Agripa]

I have a Powerware 9120 for my home systems and it is a currently manufactured online system.

Correctly designed and built switching power supplies should be very tolerant of input power problems. Typically a 120V input power supply will operate correctly from 90 to at least 140 volts without any problems and because of the capacitor input section will be very tolerant of noise and other power problems.

Be careful with international power supplies because some of them list 90 to 240 volts but use a standard voltage doubler with automatic switching which allows them to support a input voltage of 90 to 140 OR 180 to 280. If your input voltage is between 140 and 180, they can seriously malfunction.

Re:none do this anymore

[JohnFluxx]

Interesting.

Btw, you say "up to 240V"..
A work collegue (electronics guy) found his mum's computer crashed all the time. She also lived right near a generator, and he found the input to be 270V. He sent graphs of his recordings to the company, and then sorted it out, which fixed the crashing ;)

Re:How about a undo or at least a trashcan/undelet

[grumbel]

I have a 120gb drive and only around 20gb real data, maybe 10gb for the OS itself, add a another 30gb random junk to that and I still have 60gb of my HD virtually completly unused. Even if tempfiles are not handled special it will take basically forever before my filesystem fills up, its really a non-issue these days.

Beside that, I am taking about an 'intelligent' trashcan, not these "Your trashcan is full, please empty manually" ones. If the HD fills up, the trashcan should of course free itself and overwrite old stuff, possibly with custom threshold and such, no problem there, since in most cases you will find the error you did that lead to file loss relativly quickly anyway.

### Even the MSDOS undelete only worked provided that you didn't overwrite the data with something else (if I recall correctly).

Yes, it did and its undelete weren't much powerfull or anything, but it was there and it worked already quite fine on old 386er with lausy 200mb harddrives, hardware improved quite a bit since then, undelete features however didn't for no obvious reason.

### In the end I think we would be better served by a smarter 'rm' and a better GUI trash can (not the cheap hack the KDE team came up with).

Such stuff will NEVER be enough, I don't actually 'rm' my files, in most cases I overwrite them with 'convert', via piping or whatever. And thats exactly the reason why I want undelete at filesystem level, since the filesystem can track all these without problems, something implemented at the GUI level however can only ever track a very small fraction of excidental deletes or overwrites, if at all.

The hardware to handle a versioned filesystem without problems has at least existed for a decade, its really just the software that still hasn't improved, neither on Linux nor on Windows or MacOS.

Re:Your .sig

[Eccles]

I do, however, have a problem when this griping becomes the gross, slanderous, racist mischaracterization of the inhabitants of the Indian subcontinent.

Can you point to anywhere on /. this has occurred and has not been moderated down, flamed, etc.?

Re:Your .sig

[SubtleNuance]

Im sorry -- excatly in what instances, in what context has this "gross, slanderous, racist mischaracterization" taken place?

Ive seen no instances where this has occured let alone be acceptable...

Or, be honest, was I a little closer in my original query..

Awesome. Any moderators care to do their job?

[Anonymous Coward]

Where's a positive moderation when you need it?

Patch against 2.6.8.1 ?

[LinuxDag]

Is there a patch available that applies cleanly against 2.6.8.1? The one on namesys.com will generate quite a few rejects and I don't have the time to tweak the files manually just now. Eager to try it out though!

Re:Patch against 2.6.8.1 ?

[TeknoHog]

The READ.ME clearly states which version of Linux is required. It's some funky 2.6.8-rc2-mmsomething. I for one wait for Reiser4's inclusion in the vanilla tree. Meanwhile I'm testing XFS and JFS too see how they stack up against Reiser3 (which I've used without problems since early 2001).

ext3 vs reiser question

[pnutjam]

From anecdotal evidence, running Linux on a 366mhz pentium and a 66mhz pentium, it seems that ext3 is much faster then Reiser. Is Reiser more CPU intensive then ext or is this an anomoly?
Speed benchmarks are great to go by if you have a newer system, but I swear Reiser was like molasses on my old ass servers and ext was at least barely usable.

Replying to your .sig

[Anonymous Coward]

If you object to "hacker" being used instead of "cracker", then why do you "surf" and not "browse" the Internet?

I SURF the Internet because it makes me sound like a buff, tanned physical specimen from California instead of the sort of pasty east-coast intellectual who lurks in bookstores and libraries. I object to HACKER because it also sounds wimpy and non-physical, while CRACKER sounds like a huge guy from Georgia who simultaneously wrestles alligators and chews tobacco.

I mean, obviously!

Re:cd into files for attributes.. neat...

[otis wildflower]

Maybe making the filesystem database work more like a relational database is what you really meant.

Ummm....

No.

Be already ha(d|s) a relational filesystem. However, building a mountable frontend to a DB could be interesting for a number of reasons, including robustness, portability, and flexibility. With a 'filesystem' schema standard that can support indexed attributes, searchability, snapshots, clustering, atomicity, remote mounts, all that stuff, and which can be implemented vendor-independently so you can run it on any DB, and create per-OS frontend filesystem modules...

More interesting IMHO than even BeFS, which IIRC isn't networked or doesn't support snapshots or atomicity...

OS X?

[jafac]

Many Linux projects have been made available on OS X in the past two or so years. I don't suppose something like this filesystem could be easily adapted though. Anyone know?

ReiserFS Plugins vs. Windows Filter Drivers

[Commykilla]

Just out of curiosity, does anybody know how ReiserFS "plugins" differ from Windows file system filter drivers?

Re:Your .sig

[ScumericanNazi]

or, "SubtleNuance", be honest; if people say things that you don't agree with, you like to force words down their throats by using subtle language constructs like "Or, be honest, ....".

You're probably a control freak, with above average intelligence and good observational powers, but who thinks his IQ is twice its actual level. Must be sad, the way all the girls avoid you cos you're so "smart".

Scumerica - The Land of the Free*
(* must be 18 years or older, US citizen, with valid health insurance, some restrictions apply)

think this through

[dekeji]

ReiserFS has a bunch of new features, like the ability to use files as directories. The people who created ReiserFS intend for those features to be used for functionality like ACLs, multiple streams/forks, etc. Those are features that application programs see and access. But if you write software that relies on those ReiserFS features, you won't be able to use that software with any other Linux file system because no other Linux file system supports those features. So, the question is whether software newly written to work specifically with ReiserFS can be backwards compatible with non-ReiserFS file systems. If it can't be, people will be reluctant to use the ReiserFS features. And I'm saying that creation of a user-mode emulation of ReiserFS features would help the adoption of ReiserFS.

The question of whether existing programs are compatible with ReiserFS is a separate question. It is not obvious that they are. For example, if ReiserFS allows "cat > foo/bar" to succeed even when foo is a file, some existing software may start failing. Furthermore, existing UNIX utilities won't work correctly anymore; for example, "cp -a" or a tar pipe won't make full copies of a directory tree anymore.

Re:How about a undo or at least a trashcan/undelet

[agrippa_cash]

I believe that there is a utility called libtrash which moves deleted files to a trash folder. I know verly little about how it works, though it is not tied to any filesystem.

What I really want to know...

[Ayanami Rei]

is what the hell kind of shitty tool Hans used to make those abominations.

The tree diagrams are nice, however.

ext3 derived from XFS????

[tabrisnet]

I have no clue where you got the idea that ext3 is based off XFS. ext3 doesn't even use extents. Tho there have been discussions of an extension/adaptation of it using extents. there is also the discussion of htree support. personally, I think it should be named ext4 then...

XFS doesn't [have to] blockalign files either. ext2/3 does. ext3 uses full blocks for directories (to store dentries). XFS doesn't (though it will, after a couple dozen dentries). Reiser allocates incrementally, never going for a full block for directories.

Anyway, I don't see how ext3 relates to XFS except both are journaled FSs and may use similar theories. At which point one may as well claim its related to NTFS or JFS or even JFFS

Re:ext3 derived from XFS????

[Anonymous Coward]

Arrey man,
You don't understand yaar. Why does ext3 get funny when xfs and jfs and resierfs don't get as funny? You know ext3 just sits there asking for fsck. But then there are times when reiserfs after a power faliure will go down and it will get all fubared and ask for resiefsck. Why does it do it.....?

Sorry for the colliqualism on the english. time to make the dohnuts.

Anti-Semitic signature.

[Gendou]

Jesrad:

I followed the link in your signature and read the entire story. Frankly, I'm a bit disturbed by what it's implying.

It is an interesting story, and it does do a good job of explaining many facets of economics (anyone who understands that inflation is an intrinsic part of our economic model will recognize that much of the story is based on real concepts), but I can't help but wonder how you managed to overlook the not-so-suble anti-Semitic overtones.

The "secret cartel of bankers running the world and controlling the media" theory is exactly what you see on the typical anti-Semitic website, and the fact that the article conceals its racism by not specifically mentioning Jews does not absolve it of responsibility. "Fabian" is portrayed exactly like a sterotypical "secret cartel" Jew that right-wing paranoids will endlessly ramble on about, and the other bankers are portrayed the same way. The artwork supports the racism of the article. Look at this picture (if the link doesn't work, search the page for the phrase "Goldsmiths from other towns") of the group that allegedly controls the economy, the government, the media, and the world. Do you think the giant noses and obvious Jewish caricatures were an accident? That's exactly the same artwork style that's been used in racist cartoons (WARNING: offensive links) for years.

Let's look a bit further at the story:

1. The "bankers" (i.e. Jews) are accussed of controlling the government from behind the scenes.
2. The "bankers" are accused of manipulating the economy through moneylending in order to avoid ever having to work. (This is the most persistent anti-Semitic stereotypes.)
3. "Fabian and his friends purchased most of the newspapers, T.V. and radio stations and he carefully selected people to operate them." (This is another of the most presistent anti-Semitic stereotypes.)
4. The "bankers" are quoted as saying to each other, "It is our right and duty to rule. The masses don't know what is good for them. They need to be rallied and organised. To rule is our birthright." This is straight out of any piece of Nazi propoganda that you care to pick up.
5. An angry Jewish-looking man is portrayed sitting at a desk inscribed with dollar signs and "eye in the pyramid" symbols (another favorite of conspiracy loonies).
6. The Federal Reserve system is portrayed as being a front for "private lenders", which is in turn portrayed as being a front for an obscured building with a quesiton mark on it that looks a lot like a Jewish temple.
7. The story then descends into standard Christian fundamentalist "New World Order" paranoia, implying at the end of it all that our Jewish-banker protagonist is actually the Anti-Christ himself... a favorite theory of the racist Christian Identity movement. At the end of the story, he's seized complete control of the world (through the standard method of tattooing "666" on everyone's hand) all because we didn't listen to the rantings and ravings of the violent racists who tried to "warn" us of the "great Zionist conspiracy."

Okay, so the story starts with sound economic truths and then starts to blend in racism and hatred through misleading assumptions, half-truths, and outright lies. This is hardly out of the ordinary for hate groups that want to be racist without admitting to being racist. I'll admit, the story isn't as

Re:Anti-Semitic signature.

[Jesrad]

I don't think it refers to jews in any way (that's not something I remarked at all when I first read it), you're seeing racial slurs when there are none out of habit, maybe ? The text does indeed imply that some rather wealthy people own and control a lot of things, but hey, everyone has a different opinion on who it truly is (conservatives say liberals do, liberals say the opposite, neonazis say jews do, and a lot of other people think it's Masons / Illuminatis / Third Reich descendants / alien invaders / blacks / prairie squids / etc...). It's not like the far right wing has the exclusivity on loonie conspiracies.

Maybe you should research who owns the Federal Reserve ? That would probably help clear this up.

I concede, though, that the artwork that was added to the original text has a right-wing racist tone to it, and that the end of the text goes a bit too far in the Illuminatus-style denouncement of a conspiracy. I'll probably write my own version of the text so that these do not get in the way of rational and factual arguments.

In any case, that sig is temporary, I'll revert to my good ole Principia Discordia link soon. In the meantime, I'd have disturbed and confused some more people ;)

I like Reiser4

[smartdreamer]

I use it on my production machine and it is rock solid. You want to know how much?

Here's the story...
My computer crashed because of a power failure. I booted, everything was fine. Even the bash process continued running with no power!! Amazing you say? I dropped the computer in the furnace by inadvertency (at 600F for an hour) and in spite of the destruction of the hard disk, no corruption at all. Reiser rebuild the hard disk bit per bit. Now if this is not rock solid, what is?

Obviously, this isn't a real story.
But believe me it's the greatest filesystem; in the world in stability, performance and capability. The plug-in architecture is completely new.

There is nothing left behind in Reiser4, no fs can compete. That's it. Give it a try.

Re:Your .sig

[Zider]

That spelling is not much worse than an early morning keyboard slipping. And why would that affect the argument? The point is still valid, even if it's misspelled.

Reiser4 is a mistake.

[pH7.0]

http://www.uwsg.indiana.edu/hypermail/linux/kernel /0408.3/0494.html

>Subject: silent semantic changes with reiser4
>From: Hans Reiser
>Date: Wed Aug 25 2004 - 13:32:17 EST

>I allowed myself to get talked out of a final top >to bottom code audit, and obviously that was a >mistake.

>It will probably take about 6 weeks. Apologies >for wasting your time before that was done.

>Hans

New file semantics

[nurulc]

I have been reading some dissenting voices about the Reiser4 file semantics and the problems that this will present to the Linux community. In a nutshell every file now would look like a directory and can be opened as a directory. The names in that directory are not new files but meta data associated wit the file. This is well documented by Has Reiser on the Namesys site. This change is in some way sneaky, but in reality Hans has been writing about it for years - most of us did not pay too much attention. The immediate response in the community has been that this is too big a change and should be withdrawn.

I humbly propose that this is a challenge we should face head on now or we may not have an opportunity to do so in the future. The best way for open source to fight patents is to create prior art and you can only create prior art if you have a problem to solve. WinFS is going to give Microsoft the opportunity to discover the problems that have to be solved when faced with a file system that offers rich meta data. IMHO we have to innovate to prevent patents corralling all open source development to the old Unix domain. The only way we can fight patents is to create prior art. If we are too conservative about the challenge of change we will have to be simply spectators while the like of Microsoft patent all the 'trivial ideas' around the rich meta-data semantics that Reiser4 has to offer. We should give to the community the opportunity to discover and solve the problems that using new ways of looking at files and information that we will face.

I am generally of the opinion that much of the 'innovation' in computing is largely trivial or useless from a long term point of view. A few years ago we were told that Unix was a relic of the past and Windows NT was the operating of the future - well we see the future has to reinvent that past relic 'bit by bit'. We now see that Microsoft had many good ideas but also may worthless ones and they are having to retro-fit much that had been implemented in Unix all those years ago. But it has not been a one way street, we too have borrowed many ideas from Microsoft also.

The challenge of WinFS is not that it will be so great, in the beginning, but that it give Microsoft first crack at tackling and patenting all the trivial little solutions that integrating the WinFS into an existing computing environment poses. If we faced those issues first we have the opportunity to create the prior art necessary to defend against the, mostly trivial, patents that Microsoft and other will be filing furiously. If we are too conservative, there will be no prior art to face the challenge. Whatever your opinion about patients they will stop us dead in out tracks if we do not innovate first.

The new file semantics is both a challenge and an opportunity and one that the 'many eye-balls' of open source should brilliantly demonstrate. Yes this changes the way we view a file system and what it can be used for. As other have mentioned user space solutions would be unworkable because of the huge task of getting everybody to agree on libraries and converting the huge number of applications to use common libraries - the kernel is the common library all applications are forced to use. I strongly agree with Hans that the semantics should not be removed from Reiser4 but here lies the challenge how do you write a simple file copy utility, we can not longer use a simple OPEN, READ, WRITE, and CLOSE and get a perfect copy. But of course it has never been that simple to actually copy a file - files have always had other attributes (security, timestamps, ownership).

Perhaps we have always needed a separate form of file open - OPEN_READ_WITH_META_DATA and OPEN_WRITE_WITH_METADATA (choose any name you like). This form of open would maintain the original 'file as bytestream' concept and would read all the metadata first followed by the actual data for the file. Clearly the encoding of the meta-data is left as an open question (I would prefer the meta-data be encoded in XML utf8 forma

Re:Dupe?

[Anonymous Coward]

Fuck off. You are not funny.

Re:Your .sig

[Anonymous Coward]

As much as I detest Microsoft, I've reached the conclusion that the GPL is a greater long-term threat.

Just curious, would you be willing to explain your reasoning in your journal? A debate over the issue recently came up in one of my CS classes, and I'd be quite interested to hear your take on it.

-- Al

fscking a mounted partition

[StupidKatz]

If you can remount the partition in question as read-only, then you can fsck it without risking data corruption.