login
Search
In the debate following Andrew Morton [interview] posting his plans for 2.6.13 [story], the existence of a plugin layer in Reiser4 was discussed. Jeff Garzik put it blunty, "the plugin stuff is crap. This is not a filesystem but a filesystem new layer. IMO considered in that light, it duplicates functionality elsewhere." Andrew Morton went on to explain, "I think the concern here is that this is implemented at the wrong level. In Linux, a filesystem is some dumb thing which implements address_space_operations, filesystem_operations, etc."
Hans Reiser noted, "please remember that this is per file, per item, per node, per attribute, per disk format, per bitmap, per super block, etc., abstracting, not per filesystem abstracting." He explained a couple advantages to plugins being that it makes it much easier for developers to change the disk format, and allows for easy code reuse. He added, "the use of plugins forced all the programmers to think about reusability at every layer of design. V3 of reiserfs is way too hard to work on and modify. If you ask one of the team to code something for V3 instead of V4, they quietly groan at the thought. It is just so much easier to do in V4."
Andrew Morton replied, "advanced features such as those which you describe are implemented on top of the filesystem, not within it. reiser4 turns it all upside down. Now, some of the features which you envision are not amenable to above-the-fs implementations. But some will be, and that's where we should implement those." The lengthy discussion continued, an interesting read for Reiser4 supporters and detractors alike.
With the release of 2.6.9-mm1, Andrew Morton [interview] offered a quick status update on a number of patches in his -mm tree [forum] that are 2.6-mainline hopefuls. For example, regarding the much debated reiser4 filesystem [story], Andrew said that he is still "not sure, really. The namespace extensions were disabled, although all the code for that is still present. Linus's filesystem criterion used to be 'once lots of people are using it, preferably when vendors are shipping it'. That's a bit of a chicken and egg thing though. Needs more discussion". And as for Ingo Molnar [interview]'s preemption and low-latency fixups [forum] Andrew offered, "I haven't really thought about it and haven't looked at the patches yet. Hopefully 2.6.10 material."
Other projects specifically mentioned include the sysfs backing store, the ext3 reservations code, the ext3 resize code, kexec and crashdump [story], perfctr, cachefs, cpusets, and the md updates. Read on for Andrew's comments and the complete -mm1 changelog.
Continuing the debate over the right way to go about implementing some of the features found in the newly released Reiser4 [story], Hans Reiser asked Al Viro to clarify the issues he thinks could arise from the current implementation. The result was a brilliant explanation of what problems Al sees, specifically related to dentry aliasing, and how the current VFS architecture handles some of these problems.
Read on for Al's response and further clarification from Linus Torvalds. The interesting exchange provides some good insight into the Linux VFS layer.
Reading through the lengthy debate on the lkml titled "silent semantic changes with reiser4" [story] is a time investment. Comprised of well over 500 emails and growing, I include here a tiny snippet containing a discussion primarily between Hans Reiser, Andrew Morton [interview], and Linus Torvalds. Questions raised include whether or not the filesystem should be ultimately merged into the mainline kernel, and if so how to go about this. Much of the debate is regarding extensions that are currently only available through reiser4, and perhaps not fully compatible with existing utilities. The thread within begins with some coments by Andrew, who suggests that if the provided feature set is the desired direction for the Linux kernel, his preference would be to "accept the reiser4-only extensions with a view to turning them into kernel-wide extensions at some time in the future, so all filesystems will offer the extensions (as much as possible)".
As quoted earlier [story], Hans stressed that it was important that the reiser4 functionality be merged so that Linux is capable of competing with WinFS and Spotlight. The argument was continued by others, and to these followup comments Linus retorted:
"Hell will freeze over before Microsoft does a filesystem right. Besides, WinFS is likely almost in user mode anyway, ie mostly a library, rather like the gnome people are already doing with gnome storage. So there's really no point in trying to push your agenda by trying to scare people with MS activities. Linux kernel developers do what's right because it is _right_, not because somebody else does it."
As expected, merging Resier4 into Andrew Morton [interview]'s -mm tree [story] brought with it a lot of additional features and semantic changes. Christoph Hellwig expressed some unhappiness over these semantic changes, spawning a lengthy thread on the lkml. Specifically, he mentioned that the handling of files-as-directories (multiple streams within files) could cause problems to user-space applications, and could cause other dcache problems.
A lot of opposition was expressed. Some mentioned that the handling of multiple streams is really a userspace issue, whereas others mentioned that legacy applications may not properly handle multiple streams which could lead to the loss of user data. This lead Hans Reiser to say in support:
"Andrew, we need to compete with WinFS and Dominic Giampaolo's filesystem for Apple, and that means we need to put search engine and database functionality into the filesystem."
With the release of 2.6.8.1-mm2, in addition to a probable fix for the memory leak some reported when writing audio CDs [story], Andrew Morton [interview] announced that the long awaited [story] Resier4 filesystem has been merged into his -mm patchset [story]. Hans Reiser provided some information about the history and usage of Reiser4, beginning:
"Reiser4 is a file system based on dancing tree algorithms, and is described at http://www.namesys.com. One should be able to get it up and running just like any of the other filesystems supported by Linux. Configure it to be compiled either builtin or as a module. Create reiser4 filesystem with mkfs.reiser4, mount and use it. More detailed info can be found at http://thebsh.namesys.com/snapshots/LATEST/READ.ME."
In question and answer format - questions from Andrew, answers from Hans - we go on to learn where to obtain the latest Reiser4 tools, and about the current limitations of the filesystem. Hans explains, "Reiser4 has [only] been tested on i386 [...]. Quota support is not ready yet. Should be ready soon. [...] Only the very core functionality is working. Exotic plugins, an API for multiple operation transactions and accessing multiple small files in one syscall, compression, inheritance, all have been postponed until after the core functionality is shipped." Read on for more information, including tips on benchmarking the new filesystem.
Mike Benoit recently posted a link to results from his new and improved file system shootout, using better hardware and running more tests. Using two benchmarks that are designed to measure hard drive and file system performance, Bonnie++ and IOZone, he's compared a number journaling filesystems found in the 2.6 kernel [forum]. Included in the lineup are EXT2 (not journaling, but an effective baseline [story]), JFS, XFS, ReiserFS, Reiser4, and EXT3 each compared head to head on both SCSI and IDE drives.
In Mike's summary he labels JFS and XFS as 'best bang for your buck' explaining, "While not the fastest file systems, both of them consistently perform close to EXT2, while using minimal CPU. XFS seems to be faster over a wider range of benchmarks, however it does use slightly more CPU than JFS. While JFS really starts to slow down with lots of files." As for pure speed, Mike points to Reiser4 which really shined in the Bonnie++ benchmarks, though not quite so much in the IOZone benchmarks. He suggests, "ReiserFS v4 will [definitely] be worth while keeping an eye on, especially considering some of the exciting new features it offers."
