Slashdot Mirror

i missed some details. The reason I made the DARPA distiction is because I'm also involved with a DARPA-funded project. DARPA has no such restrictions. For an example, NameSys Corporation. They're the authors of ReiserFS, and are being funded for continuing development of security features. They're location? Russia.

1) User can attach any attribute to any file, and query on those attributes. This includes joins, etc.

2) The desktop can do queries too. Want something like Lifestreams? Sort by date, across your entire filesystem.

3) Apps can do it too. Suppose the office suite stored everything this way...emails have attributes like date, to, from, subject...but this way your emails aren't in their own little island, you can search them from your desktop, or from other apps. You can assign them to projects, and pull up a project with all associated emails. Or assign people ot projects, and pull up all emails to people associated with the project. Etc.

Microsoft is working on something like this, and if they pull it off, they'll eat everyone's lunch. But they have to deal with a huge installed base, IT people tired of paying upgrades, etc. I don't know how far along Hans Reiser is with his vision, but if he can pull it off, that'd be a perfect foundation...build a special version of KDE or Gnome on top of it, change the file formats of an open-source office suite to use it, and we can beat MS to the punch, with a drastically better user interface...not better because it's prettier, or feels better, but because it does more.

I agree with the rest of your points though

NAMESYS
You all should know what they do, but if you don't try here
To prove that they are russian, try: Namesys Developers

NAMESYS
You all should know what they do, but if you don't try here
To prove that they are russian, try: Namesys Developers

Reiser4, dude!

That, my friend, is why we have Hans Reiser. He's already one step ahead of Microsoft.

I'm surprised nobody's posted this yet, but ReiserFS is working on something similar, described in this whitepaper.

Unfortunately, Microsoft has exactly the wrong platform to implement these ideas on. The whole motivation behind this kind of thing is to simplify the software. Microsoft needs to be backwards compatible with 20+ years of cruft, and they have an abysmal record for writing clean, simple APIs.

This will probably end up being just another popular software engineering idea that ends up being superceded by new business plans later on. It will become yet another ossified layer in the lower sediment of their future OSes (see DCOM, etc.).

You're a goddamn hypocrite. You're the reason why Slashdot sucks so badly. Why don't you learn how to think for yourself instead of bashing commercial developers who are trying to make a difference and bring people better products?

We still have a paradigm from old times which IMHO won't live too long anymore - the distinction between RAM and Harddrives. Already now, the virtual memory abilities or file caching blurs the distinction. Database-driven filesystems will blur it even more. Namespace integration (see Hans Reiser) should allow us to worry about data, and not where is stored - dummy users often refer to programs or services instead of devices anyway (I have this document in Word but I can't find it anymore, or: My browser does not work! When the network or server is down). Java applets are stored on a server, but by starting it I get my local copy... What if we get persistent RAM in huge amounts? Will we use it as RAM disk just to still be able to reboot?
I wish for a machine where installation will be a netboot from somewhere while I'm connected, and it will continue to work when I take it on the move (I may still be connected, who knows?). The concept of saving a file to a HD (or tape) is artificial, invented on the first, slow, restricted computers. Instead of building on old technologies with phony 'distributed computing' ideas I hope the next ten years will allow me to care about contents, not where it is stored.

I have no opinion about this news; but I hope it prompts a few more people to make the effort to read through Hans Resiser's brilliant whitepaper. The first time I read that article I was blown away by the amount of thought the guy has put into the design of file systems. The first OS to thoroughly exploits his ideas will revolutionize computing.

I'm not suggesting that vim be made reiserfs specific, but that all filesystems change to be more like reiserfs. Filesystems should all make having large numbers of files in a single directory efficient, and should also make having lots of small files efficient. So far, reiserfs is the only filesystem I know of that's realized what a virtue this is.

Read The Naming System Venture for several good reasons why all filesystems should make these things efficient. The basic idea is that having lots of different object naming systems that don't seemlessly integrate with eachother is bad.

Why not just store each line in a file named with the line's number and let the filesystem do all that ugly work for you? Oh, wait, I guess reiserfs isn't that ubiquitous yet.

Seriously, there are good filesystems that do all of this balanced block tree work for you, and you should take advantage of them. IMHO, all filesystems should efficiently handle gigantic directories and tons of small files.

Donate the time to ask your company to buy a reiserfs service contract. (Lycos-Europe will tell you it is very happy it bought a service contract, and that our service is excellent.) Estimate 1% of the storage hardware cost that is used for reiserfs (you don't need to be more than roughly accurate, and only need to update the number once a year), and that will get you a priority service contract better than what you could get from a proprietary software vendor (with us the code authors are the ones who answer your emails.) You can use paypal at www.namesys.com/support.html, or send a check, or whatever your accounting department likes to do. Take the time to be as careful to buy service contracts on mission critical free software as you would to buy service contracts on proprietary products, and there will be lots more free software in this world.

Check out Reiser'S whitepaper.

If you can wait until September 2002, ReiserFS v4 will have an encryption plugin builtin.

Ok, I can already hear the Trolls arguing which FS is superior.

Personally I'd say that it depends and it is not the point asking whether one should use ReiserFS, ext3 or XFS.

Personally I've been using ReiserFS for ages without ANY problems at all on a number of systems running SuSE, Mandrake 8 and recently on RedHat 7 and 7.1. Over the time I've been more than satisfied with the results I got regarding speed, stability and so on.

But personally I'd really like to be able to freely choose which FS to use - I really can't understand why especially redhat was ignoring ReiserFS all the time, claiming (IMHO you can't otherwise say so!) it was "unstable". This must be some kind of weird "political" or strategic question.

So my 2c: at least leave the average user the ability to choose his preferred filesystem in Distro setups and don't just simply stick to one and ignore the others as if they wouldn't exist- nobody will complain if it's set to ext3 by default for beginners. ;)

So journalling's been available to the masses for a while now. Or maybe Michael meant ease of converting for the installed base?

Now if only the damn preemptible kernel patch would make it in. Unfortunately, it looks like that's going to wait until 2.4.5. *sigh*...

As my sole 2.2 machine is running Mandrake w/ ReiserFS, I can't grab it quite yet for my firewall. Keep an eye on their ftp site for the imminent 2.2 patch, and enjoy.

Take a look at the Reiserfs white paper. It's anything but traditional.

It would appear that Hans Reiser agrees with you, at least in part. Check out Future Vision on the Namesys site. As the front page says, "the interesting stuff is still in the future." The killer file system they have now is just foundation work.

It would appear that Hans Reiser agrees with you, at least in part. Check out Future Vision on the Namesys site. As the front page says, "the interesting stuff is still in the future." The killer file system they have now is just foundation work.

Reiser4, which says to be released Sep 30, 2002 will support plugins to the file system for things like ACL's, compression, and yes encryption. Looks like a great concept.

> Or you could use a journalling fs that isn't
> just a bad hack off of an existing fs.

Reiser isn't a full journaling filesystem. It only journals metadata. ext3, on the other hand, is.

And how is it a bad hack? ext2 was designed from the ground up to be easily extendable. The near seamless addition of journaling to the filesystem shows that they've succeeded at least in this area.

- Arcadio

Amazingly, in the article Hans Reiser quoted another benchmark tests which show Reiserfs is superior.

The results too perfect to believe.......may be I'm thinking too much....

I assume that since ext3 only adds journaling to ext2, reiser is "faster" than ext3 also.

Again this is the claim of reiser people.

Ergo, I'm not hedging my bets on ReiserFS and NFS working in Linux anytime soon.

No, I've been happily serving up NFS off a reiserfs (over IDE raid-0), with no problems! I did have to reiserfsck once, but then found FAQ #3 ("What's up with NFS and ReiserFS?") at namesys. It addresses your problems and provides patches for older kernels. I've been using 2.4.3 + reiser+nfs_fixes stably for a long time now. They say in the FAQ that these patches have been incorporated since 2.4.6pre3. Go forth and enjoy, I think this combo (IDE RAID + reiser + NFS ) rox0rs!

Also, there is a patch available for 2.4.5 at the Namesys website, where they stated on June 21:
Quota and KNFSD patch for 2.4.5 is renamed ( linux-2.4.5-reiserfs-quota+knfsd+umount-fix.patch. bz2) to indicate explicitly that it also contains umount-fix patch.

Yup. Try here.
-

Try this... Not very impartial I suppose :-) But benchmarks all the same.
--

See RFS Features
--

See RFS Features
--

http://www.namesys.com/whitepaper.html is much better.

Cheers,

--fred

At namesys.com they have benchmarks that clearly show Reiser beating ext2 and ext3 on a number of Linux setups. From the comments here, I'd take it y'all think their bench is tilted? Maybe, but the speedup is obvious on a 2.2.x system from where I sit.

At namesys.com they have benchmarks that clearly show Reiser beating ext2 and ext3 on a number of Linux setups. From the comments here, I'd take it y'all think their bench is tilted? Maybe, but the speedup is obvious on a 2.2.x system from where I sit.

(I don't count NTFS, because that is hard-pushed enough to be called a genuine filesystem, never mind a journalling one.)

Feel free to reply to this, adding any that I've missed.

The Logging filesystem does much the same thing as Ext3 - it is an extension to Ext2 - but it looks like it would be a lot more useful than Ext3. IMHO, it'd be much better if neither of them were so FS-specific and could be used as a generic wrapper. SnapFS does exactly this, for example.

Anyway, on with the list of Journalling Filling systems...

... -IN- the main kernel tree:

• ReiserFS

... at a stable release:

• XFS

... at a developmental release:

• JFS
• Ext3FS

... currently abandoned:

• LogFS

... extensions for:

• SnapFS - versioning for journalling filesystems

I dont know how it compares to XFS. But go here to see how ReiserFS compares to Ext2, Ext3. (Hint: it kicks its ass). Add in journaling and you have a killer combo. XFS is a little more industrial strength as opposed to general purpose. If you're streaming gigabyte files and processing them on the fly, I imagine XFS is the way to go.

If you're like me and are just now starting to use reiserfs, they you might not have the tools to make, check, etc, the filesystem, and they *don't* come in the kernel patch. But seeing as it recommends that you use utils that match your version of reiserfs (3.6.25 in 2.4.1) then here are the recommended utils from namesys for 2.4.1 kernel.

bash: ispell: command not found

It's in the reiserfs FAQ -- this isn't strictly a reiserfs problem, but more a problem with the linux KNFSD (shipped as nfsd in many distribs).

There is a patch to fix this, but unfortunately it is against the -test10 kernel. By 'visual diff'ing the failed hunks, I have a patch that works on 2.4.0. After I test it a few more days, I will post it to the reiserfs mailing list. If you want it, mail me, or keep an eye on the mailing list archive at Namesys.

From what I understand, this patch has been held back from the main reiserfs distrib (and now the kernel proper) because it depends on a feature that is still being debated.

Much of the ultimate point of ReiserFS is the marriage of databases and filesystems (filesystems are really just a limited sort of database anyway). This is the reason for the all the commercial funding; there are people out there who really want this.

See Hans Reiser's White Paper for information on where he's going with this.

For what it's worth, database filesystems are not a new thing at all. Hans is just planning on accomplishing this in a way that completely preserves the Unix file metaphor and related concepts.

Here's a testimonial from namesys web site that helped to convince me:

http://ftp.sourceforge.net/ has 850GB storage, half of which is reiserfs, half is ext2. Both filesystems have been running flawlessly for > 4 months of production (actually longer, but wasn't reiserfs before). That server pushes between 15Mbit and 50Mbit/sec, and pulls/syncs about 2-5Mbit/sec, 24x7.

reiserfs also powers the CVS tree filesystem for cvs-mirror.mozilla.org (also tokyojoe.sourceforge.net), which is the one and only anonymous CVS checkout point for mozilla. That server has run flawlessly under very heavy load since its birth.

Hi,

as somebody else said, you really should check out www.namesys.com as soon as the slashdot effect wears off.

ReiserFS is much more than just a journaling file system with a tree structure. It has also some functionality from databases and full text search in the file name space. It therefore combines the advantages of the search engine (just enter some words), the database (strict mappings from key to value) and the classic tree structure.

It can also handle extremely small files efficiently, so that you do not have to write storage layers for your object oriented applications. If you want to store something that is 50 bytes large, you just create a file to store it, and it will not consume insane amounts of memory in your harddisk.

This means that you can boost the performance of everything that uses small files (some simple databases, mail and news servers, apache etc.) significantly by switching to ReiserFS.

People often complain that the open source software model does not produce many really new technologies: ReiserFS is one of those new technologies. It might even be the "killer application" for linux two years from now.

greetings,


AC

Link is wrong, it should be http://www.devlinux.com/namesys which redirects you to http://www.namesys.com/.

Thimo
--

www.namesys.com

The first thing I did when I found out 2.4 was out was head over to Namesys to see about that. From the FTP site:

- 306954 Jan 5 09:49 linux-2.4.0-reiserfs-3.6.24-patch.gz

It's there. Gtab it. Have fun. A link for the impatient: ftp://ftp.namesys.com/pub/2.4/linux-2.4.0-reiserfs -3.6.24-patch.gz.