Slashdot Mirror
Interview With Reiser4 Author Hans Reiser
An anonymous reader writes "KernelTrap has an interesting interview with Hans Reiser, the author of two revolutionary Linux filesystems, Reiser3 and Reiser4. Reiser3 was the first journaling Linux filesystem. Reiser4 is a complete rewrite that is claimed to offer amazing performance and a new plugin architecture offering semantic enhancements to rival Microsoft's WinFS and Apple's Spotlight. Comparing Reiser4 to WinFS, Reiser says in the interview, "Reiser4 is a much more mature design, representing a 10 year effort"."
I am Hans, and this is Franz, and we want to [clap] journal your filesystem.
Ya. Ya. All you little girly men with your FAT and NTFS!
Really, Ya. Makes me sad to see such pathetic file systems!
Here's a link to the page that hides the asshats making the pages super-wide with lame comments.
This one is pretty old review back when Reiser4 was still Experimental. More recent one would be here, but it too is over a year old.
-----BEGIN PGP SIGNATURE-----
12345
-----END PGP SIGNATURE-----
Anything more specific? I'm the first to admit that he can be rather immature, spoiled and inflammatory but a quick look at the link you offered showed none of these attitudes. Actually the discussion sounded quite civilized, so what's the problem?
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
If benchmarks are even halfway legit, then this is indeed something amazing.
Never attribute to malice that which can be explained by mere idiocy.
There's a beta version available to developers now. There was a lot of criticism of it when it was first unveiled so they went back to the drawing board and released a new version that claims to address those concerns.
This is my sig.
XFS beta came out 9/22/2000 (its source code was first publically available on 3/30/2000) The first journaling version of reiserFS was release in november of 1999.
JFS came later than XFS though I can't find the date.
Of course officially ext3 came out before reiserFS in september of 1999, though ext3 is the real winner. Which produced workable code first I have no idea.
It's an INTERVIEW with the system's author and he's giving his opinion. Which, come to think of it, is what one DOES in an interview, you know, ask someone what they think? Sheesh.
Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
My understanding is that the kernel developers have pointed out flaws in the benchmarks and he has accepted the criticisms but points out that they are just benchmarks and all benchmarks have flaws. This would not be a problem if he didn't keep referring to the benchmarks when trying to ram a change into the kernel. You can't have it both ways.
It's also my understanding that the key reason kernel developers don't want to accept his patches is that they don't like big megapatches that affect many systems or replicate functionality that is already in the kernel -- it's bad for maintenance. It's also my understanding that he doesn't want to break up the patches himself and he has refused help from others who are eager to do it for him. For him, it's an all or nothing deal -- take it or leave it. The kernel developers say "fine, we'll leave it", but he doesn't accept their decision and continues to complain. Again, you can't have it both ways.
Reiser may be a genius, but even geniuses have to (*gasp*) live in the real world and negotiate with real people. Even if Reiser is smarter than all the kernel developers (doubtful), it pays to treat your so-called "inferiors" with respect. Even janitors and garbage collectors can have wisdom that we don't have and things they can teach us.
One of the driving concepts behind ReiserFS is that metadata is nothing special, and it should be presented in the same namespace as the files themselves. If you read the article, it talks about using 'cat' and other simple tools to manipulate the metadata. Think something like 'cat /home/foo/music/some.mp3/artist' to display the person who performed a song.
It depends on the metadata. Think about file permissions. That's metadata. All the files you create are given defaults based on your umask, and you can go in and change them at any time.
In order to expose some of this metadata to the end-user in a GUI, yes, there will probably need to be some new UI work done. It doesn't all just magically work, it has to be presented to the end-user in some way that will make sense to them. So what I would expect is that the filesystem and plugins will be finished and done, and able to be manipulated by programs and shell scripts, and then it will take further work to integrate this metadata support into GUIs and file managers in a way that's useful to non-power-users.
Bogtha Bogtha Bogtha
Yeah, that's not a good link. Try this kerneltrap one. Things have been brewing. I haven't kept up with the most recent stuff, though.
;) If I butchered anybody's perspective, please correct me. I don't do kernel dev or psychology.
It's really a design/people issue. There are the lingering issues of stability and similar, but these are not (as I understand) the original problem.
Reiser4 incorporates some sophisticated metadata concepts ("semantics") that are in effect a software layer over the fs - which is why Hans can compare it to WinFS. Some of these features step into the functionality domain of the VFS and the kernel. Not a bad thing, per se.
Now, we all know the stereotypical kernel dev - technically conservative, concerned about maintenaince, not really keen on making big compromises, and annoyed by ego (again, a stereotype). Keep that in mind.
Hans of course wants Reiser4 into the kernel. What's the holdup (from a technical design standpoint)? Well, individuals like Andrew Morton want functionality in the kernel that can be reused in a file-system nuetral fashion. Reiser4 has a plugin system, but it's a Reiser4 plugin system. Reiser4 and Hans want to extend Linux as an API, which right now will just be for Reiser4.
There are also some lingering details of how this will change the course of filesystem integration in the kernel, in regards to traditional POSIX and Unix-like behavior. I don't recall any enduser problems, but there are few complaints.
Why might this be annoying? Well, Hans wants his fs into the kernel now and he makes the case of its superiority, the markets demand, and the need to compete with companies like Microsoft. I wouldn't be the one to tell kernel devs that they need to compete with MS, but Hans is - to say the least - confident. And he did name the filesystem after himself, so I'm not how this couldn't be personal on some level.
The middle ground is to say to Hans: we'll take Reiser4, but we want these Reiser-only features to be ultimately modified for all capable filesystems. Hans insists - and I'm sort of generalizing here - that the details can be sorted out, but right now we should go with Reiser4 and not worry about making it anything but a great fs.
So, Hans took a "assertive" position on why Reiser4 should not only be included in the Linux kernel but also change the kernel. Linus, Morton, and a few others took a stand and said - in so many words - "Hans, we aren't putting your ego into our kernel. Not even experimental."
It would be interesting to see if end users put enough momentum behind Reiser4 to put in into mainline or start it in 2.7.
Is that worth a few flames?
This is a type of question that, unfortunately, cannot be answered correctly. Well, it can: it depends. But that's not what you are after. As Hans himself pointed out, there are some fsync performance problems with ReiserFS. If you look at PostgreSQL config files, you'll notice a "fsync" setting, and if you look at pgsql-performance mailing list, you'll see frequent mentions of fsync. Obviously, fsync affects DBs (not just PostgreSQL), and ReiserFS may not currently be so great for DBs. However, it is apparently good for large directories (1 directory, lots of files in it). So, it depends how you use your FS.
Describe how you use your FS, and maybe somebody can provide good feedback.
Simpy
Are you sure you understand what ReiserFS is suppose to do? What about WinFS? I don't think compairing WinFS to ReisierFS is quite like compairing Qt to Explorer. The functionality of WinFS is (as I understand things) a proper subset of the functionality of ReiserFS.
Again, there purposes are not really different. Sure, ReiserFS is a full blown filesystem, and WinFS is not a filesystem, however the functionality of WinFS is included in ReiserFS. The fact that they operate at different levels is the reason for Reiser's remarks concerning ReiserFS and WinFS. That's his point. WinFS works on a user level to provide functionality that ReiserFS provides at the filesystem level, and Reiser feels that this is a more mature design.
...interesting if true.
I never said the above words attributed to "Rieser".
I am sure of it becuase I would absolutely never say that "Linux kernel developers do what's right because it is _right_, not because somebody else does it.".
I am just not that nice a guy that I would say such a thing.:-/ I am guilty of saying the opposite at various times. I am known for this, and not particularly liked for it.:-)
This is a forged quote. Note the false defensiveness put into it in the sentence "So there's really no point in trying to push your agenda by trying to scare people with MS activities." That really sounds like someone at MS posted this.
It does not matter so deeply that MS put it into or out of the kernel, what matters is how they layered the code relative to itself --- that is, do they use the FS API, which lacks an insert or excise operation, to repack small objects that they squished together within a file, and does that layering make things slow. I think it almost certainly does make it slow, and it definitely is inelegant.
Hans Reiser
Reiser4 Architect
Namesys
If your not smart enough to remember how you file things, how are you going to be smart enough to remember the metadata needed to extract the files out of a database?
Remember what?
When I query something, I query what I _want_. Filesystem should provide me my files - there's nothing to remember. I'm already quering amarok interface with song names and it doesn't hurts. Same for spotlight - people likes it.
Second people complain of Resier4's system overhead
I don't understand those complains. I've seen benchmarks where reiser4 eats the double of CPU time than other filesystem. But then, it finishes the task in half of the time.
Which is the whole point of a filesystem, mind you. If your filesystem is eating few CPU cycles, it means it's wasting time waiting for the disk. In a "perfect world", any filesystem would eat 100% - it'd avoid all the I/O. Reiser 4 complains about eating too many CPU can be partly because it is fast at I/O. I guess their algorightms are also very complex and burn lots of cpu cycles too - if you want to avoid I/O you need complex algorithms after all, right?
CPU cycles are cheap. What do you prefer, a fast filesystem which doesn't eats cpu cycles (because it sucks and spends all the time waiting for the disk) or a filesystem which eats CPU power because it is fast?
Well, what I want to know is: How do I get to this metadata? Some extra tool? Some right-click option that I have to select every time I create a file?
Anytime you save a file today, you're already manually specifying several pieces of metadata: the filename and the location.
Anytime you access a file today, you're already manually specifying that metadata also.
Consider how many clicks it takes to (graphically) navigate to a file from the root directory. That is exactly the number of metadata labels that you yourself supplied for that unique file's creation.
So, the obvious generalization of this is to get rid of the hierarchy concept entirely. Then, as an earlier poster described, I can naturally tag my music by artist and by genre, instead of using symlinks to cut across trees.
More practically, it would allow applications to install themselves using a unique tag, so that uninstalling (or moving, or archiving) the application requires just one query on just one tag, and is guaranteed to turn up any associated file regardless of its "location."
--
Dum de dum.
Freedom is not the license to do what we like, it is the power to do what we ought.
Another thing I thought sounded cool was the ability to cat /home/foo/music/some.mp3/raw > /dev/dsp and the mp3 would just play by using a plugin that ran it through an mp3 library. This would allow application developers to just access file/raw rather than worrying about file types and conversions.
If I'm writing an image viewing program I no longer have to worry about hooks to libjpg, libungif, libpng, libevery image file type available. Let the OS care about file types and let applications deal with raw data and focus on interface rather than file types.
Paying taxes to buy civilization is like paying a hooker to buy love.
I just come from a time and place where being objective and modest about your own trade or art speaks far stronger than unmodest self-PR work.
Having read the entire interview, I found nothing in it that made me think of Hans Reiser as engaged in unmodest self-PR work. Contrary to the tiny snippet you quoted, he doesn't slate WinFS. He says that it is doing interesting work. Nor is it particularly immodest to say that his file system is considerably more mature when he's spent almost 10 years more on it than the other.
Reading the article, the parts that you consider immodest seem to me, to be just sincere enthusiasm for his work. And there's nothing wrong with that.
Contrary to the title being "no one cares", I think the replies so far show that people do.
Aide-toi, le Ciel t'aidera - Jeanne D'Arc.
More CPU % time is used because Reiser4 is faster. What should be compared is the overall CPU power needed for a filesystem operation. And even if reiser4 is really using more CPU, remember that the CPU power is growing much faster than hd speed.
Wondering why i am doing so strange posts? I am trying to get a "+5,Flamebait" or "-1,Insightful" rating.
There's nothing a janitor or garbage collector can teach me or you, or most others on Slashdot.
How about humility?
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Sorry, but ReiserFS v4 is a tiny subset of WinFS. I would say that the grandparents analogy is apt.
To clarify: ReiserFS adopts database concepts in two ways. It uses a B-tree variation to allow efficient hierarchical storage layout and it uses it to allow single-process atomicity. That is all.
WinFS on the other hand is an actual factual relational database (actually parts of MS SQL-Server) built on top of NTFS; a NTFS file is a special datatype among many others. One can specify relations and constraints as one would in a relational database. It has full atomicity (ACID), whereas ReiserFS's atomicity just gives a rollback local to a process. That is, any read or write may be transactionally inconsistent if there is more than one process dealing with the data whereas in WinFS one gets full support for transactions.
In addition to the above WinFS of course provides the obvious big end-user features; Fast queries over all the data in a relational way, and triggers that allow actions performed when data is changed or queried (both of which OSX provides in a slightly more ad-hoc way on the side).
So where does ReiserFS fit in? Well, the complaint that Hans Reiser has against WinFS is that not everything is a file, rather files is a special case mapping down to NTFS streams. Small auxilliary data is handled by other data-types in an SQL-like manner in WinFS, which to me at least seems like a quite sane approach. ReiserFS instead just optimizes the heck out of small files, planning to just take the UNIX principle to the limit, everything is a file, even if you just want to store a small integer. This makes everything fit into the classic filesystem namespace in a good way, but it is really less structured than the WinFS approach. WinFS relates whereas ReiserFS just provides really fast unstructured primitives.
Overall I don't expect ReiserFS to be overly relevant to the OSS answer to WinFS, mostly because I don't really expect a OSS answer to WinFS on that level. While Microsofts approach is a great piece of engineering is is also a huge amount of work. More likely is that the Apple approach will continue to be the important one; Just add the stuff needed to get the actually important end-user features today, work on the low-level programmer features later.
On the other hand ReiserFS v4 really appears to be very very fast. No doubt great features can be built on top of it, but on the other hand the classic VFS abstraction is a good thing. Swapping filesystems without impacting the userland is a feature that is really useful, so it seems fairly likely that the simpler approaches like Beagle will get to add the basic end-user features instead of fattening up the file systems (I highly disagree with Reiser that it is on the actual FS-level things should happen in the future). People who need databases can, *gasp*, use a database instead.
In fact, I am suprised to not yet have seen systems like Gnome and KDE fire up a stripped down PostgreSQL process or something similar to provide applications with an excellent database for whatever their needs might be. For Microsoft doing a thing like that hurts the bottom line (they do charge a fair bit of money for SQL-Server after all), but there is no reason why an OSS platform should not utilize the best technology it has available at every turn.
Oh well, getting off track. Summary: ReiserFS v4 is a tiny subset of WinFS feature-wise, it just does it very very fast.