Slashdot Mirror
Ask ReiserFS Project Leader Hans Reiser
Hans Reiser leads a successful Free Software project that has attracted plenty of attention, many users, and even that Holy Grail of so many who have started their own Free or Open Source projects: Big-time funding from DARPA, SuSE, and others. How did he do it? What's his advice for other project leaders? Ask him! And ask him any other question you have in mind. Please stick to one question per post, and avoid questions that can be answered with a few minutes' worth of research. We'll publish Mr. Reiser's answers as soon as he gets them back to us.
When you look at your Linux installation scripts today, you see that ext3 is all over popular distrobutions like RedHat. ReiserFS used to be the most popular journaling filesystem for Linux, but how will it shape up given the mass adoption of ext3?
--------
Free your mind.
What specific benefits would I see by switching my box to ReiserFS as opposed to EXT3 or one of the many other journalling file systems that Linux now supports? At this rate, seems like I could be reformatting my hard drives every week.
Now you just need to hire someone to desire a modern, more "commercially pleasing" website. =)
My main question(s) is this(these): Is ReiserFS tunable to reduce usage of a laptop HD? If not, will it? As is, it's great on low capacity (under 1 gig) drives (I'm not sure how much overhead it imposes in comparision to ext2/ext3). However, it also likes to keep the drive active, which drains laptop batteries.
--
# Canmephians for a better Linux Kernel
$Stalag99{"URL"}="http://stalag99.net";
Although its speed and (otherwise) good level of data integrity is of great interest to my employers, before I can recommend it to such a large company, I would like to know how and when you intend to put in a fix.
Comment removed based on user account deletion
What was so lacking in other file systems that you felt compelled to write your own? How do you think yours compares with the others?
I've been a fan of Reiserfs ever since I started using it, and I've been very impressed by its speed. I'm really anticipating Reiser4, and I hope it'll get merged into 2.6. However the last I heard about this is that Linus hasn't read your docs yet, and the status page on kernelnewbies shows Reiser4 to be "pending". Can you give us any insight on what's going on?
"Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
Can you clarify your long term goals with respect to ReiserFS and file system design in geek lay man's terms?
I'm refering to your Future Vision paper in particular. How would this kind of system be used on a day to day basis?
Right now any mention here of adding database like functionality to a file system is met with crude comments about SQL... Some explaination would really help.
cheers,
--
Simon
As I understand, what ReiserFS offers that "enterprise-class" journaling filesystems like JFS and XFS don't is the ability to treat the filesystem more like a database and less like a tree, but I haven't really heard of anyone getting serious about using this functionality. Why did you bother to add it, who do you think will get the most use out of it, and how would you promote it, given the chance?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Beside the finding and organizing files, the biggest problem for desktop users today is probably that changes on the file system are not recoverable. It is easy to accidentally overwrite a file and lose your work, and the only only sane way to solve these kinds of problems would be to make it possible to revert changes.
Several research systems have been created, like the Elephant File System, but none of them made it into the mainstream free and commercial operating systems. Are there any specific reasons why nobody offers recovery (high complexity in implementation, very bad effect on performance, etc) or is it just because FS designers don't see the need for it?
We ran reiserfs for a short period a few years ago because we were saving data to 10's of millions of small files, and reiser seemed like a perfect fit. We had to stop however because as we added more and more files, disk access slowed down more and more. It eventually became almost unusable and we had to switch back to ext2. How much faster is it now than it was then? Have you completely solved this problem?
(1) Software project management techniques seem to vary by discipline. Some groups follow the traditional âoewaterfallâ(TM) model others follow Rapid Programming models â" Do you try to follow a particular style? (2) Classic project management spends a lot of time accounting for resources. I can imagine that an open source project has people signing-on and dropping off. How did you keep assignments & scheduling under control? (3) Have you come up with any tips or tricks that work for managing your project that might be useful to other software development Project Managers?
In your Future Vision white paper, last modified in January 2001, you outline several very interesting ideas about metadata.
Several developements have taken place since : the extensible attributes of BeFS has been burried with BeOS, the database-like metadata of Longhorn (aka Yukon) may actually be a separate layer from the filesystem altogether, and Apple is also moving all metadata out of the filesystem to XML files shared between applications (see iLife package).
My question : What is your current take on the metadata debate ? Do you still think the filesystem is the right place to handle metadata ? Any predictions ?
Will dynamically-loadable filesystem plugins be feasible, or practical? What scope will the plugins have? Encryption/decryption is obvious, but what about more interesting things, like scan-on-access Antivirus, or perhaps a mail spool could be mounted with some kind of spamassassin plugin.
- Minimizing Inner/Outer fragmentation
- Maximising locality of reference
- Minimizing the cost of file extension
I'd like to know how Reiser FS approached these conflicting goals. Has Reiser FS used any mathematical models to evaluate long-term stability/performance?Reiser FS is already a pretty mature, stable, usable product. Once V4 is done, is there really much work left to be done on ReiserFS proper? Do you have a giant to-do list that'll keep you and the guys occupied for years, or do you intent to work in a diffent direction (SAN, networkFS, databases, etc.)?
(or perhaps you'll just retire to Portugal and play lots and lots of golf)
## W.Finlay McWalter ## http://www.mcwalter.org ##
When you began a file system project as a free software project, you must have known that (assuming it worked) it had the potential to turn into a big project. How did you determine how long to work on it as your own project before making the first release? I imagine there must have been a strong temptation to just get it "out there" knowing its potential, yet certainly releasing too soon would make it look unprofessional and thrown together.
On the ReiserFS 4 page you say that the new filesystem uses algorithms allowing the FS to do transactions only databases could do previously. Do you envision ReiserFS 4 being something comparable to MS' "SQL-FS" plans in Longhorn? How would ReiserFS 4 affect regular (oracle, postresql, mysql) database projects/companies?
Clearly Unix filesystems are moving in the direction of extended attributes. This isn't necessarily a smooth transition for Unix, where many utilities are modeled after streams of bytes.
I personally have pondered about this a lot. What do you think needs to be adapted and why? Should the VFS be changed? Should traditional Unix tools like "cat" be adapted somehow, or given attribute-aware equivalents? Should file attributes be accessable at the file descriptor level? Will we need a new "tar"? What should be done to standardize these attributes, or make them compatible across filesystems?
The directory layout of the typical unix filesystem has grown over the years to what has become the FHS 2.0.
If you were in the position of designing an entirely new FHS, more suited to ReiserFS (lots of small files, database-like access, etc) and without backward compatibility, what would it look like?
This is your sig. There are thousands more, but this one is yours.
In your future visions paper early on you talk about Reiser's Rule of Thumb #2. However, I can't find Reiser's Rule of Thumb #1 -- what is it? Is it a secret? Does it contain the sum of all human knowledge?
TELL ME!
Carpe Daemon
I've spoken to a few people (not naming names) who appear convinced that the design of ReiserFS is fundamentally flawed, and that it would lead to inevitable deadlocking. I've read your white papers now several times (took me a while to figure them out), and think the work you're doing is great, but a few smart people seem to think it can't be trusted. How would you reassure those people that their data is safe?
the redmond hegemony lost the internet protocol battle and decided to fight back with semantically rich but proprietary file systems (think 'halloween memo', 'longhorn', 'groove'). are you thinking about how to mutate ReiserFS to support arbitrary object attributes, full-text indexing, callbacks, namespace syntax for queries, etc?
I recall a discussion at lkml about the licensing issues with bitkeeper. Someone said that the future versions of your FS will have some version control built-in, and thus be a sort-of competitor to Larry McVoy's bitkeeper. Larry's comment was that if that happens, then you have to buy bk in order to use it.
You suggested that indeed version control is going to be in. Can you say more about these plans now, and the eventual conflict with bitkeeper.
Thanks.
I'm preparing by reading everything I can find: I'm working on Tanenbaum & Woodhull's "OS Design & Implementation"; I've read "Design and Implementation of the Second Extended Filesystem"; Steve Pate's "UNIX Filesystems" is waiting on my shelf; and of course, there's the FAQ and ReiserFS v.3 Whitepaper at www.namesys.com.
Specific questions: what branches of math are useful in this line of research? Any books, articles, etc., that I haven't listed that are a 'must read' or 'should read'? Those who have succeeded in building a better filesystem: what have they done that I should also do? Any mistakes I should avoid? Anything that no one told you about filesystems that you wish you had known up front? And are there any special tricks (above and beyond mastering your subject) to getting hired in this field once a degree is in hand?
Thanks!