Talk:Reiser4

From Wikipedia, the free encyclopedia

To-do list for Reiser4: edit · history · watch · refresh

Here are some tasks you can do:
  • Requests:
    • Overview of the Hans Reiser vs. Linux kernel team controversy
    • More information about the cryptcompress plugin

Contents

[edit] Stub

Well personally, this article is very scant. Its really more like a stub. In fact, if no one objects, I'd add the stub tag to it. Namely, it only generalises the features of reiserfs, does not explain why its that way...ie. it does not mention the fact that it uses dancing trees instead of B+ trees, or several other critical principles. I think we could all agree that someone who has expertise in this area should improvise. Take for example, the windows filesystem FAT32, its quite a simple filesystem, far more inferior (we can agree on that, I think, that FAT32 is far less advanced) - yet it has dozen or more long paragraphs. Surely this article deserves more? -- Natalinasmpf 04:13, 23 Oct 2004 (UTC)

The article seems to have passed the stub stage. Would anyone mind if I archived (deleted) the above comment? It doesn't seem to apply anymore, and then the TOC for this talk page could move to the top. --- Markspace 23:28, 4 May 2006 (UTC)
Problem solved. AlistairMcMillan 01:21, 5 May 2006 (UTC)

[edit] Journaling Link

The Journaling link seems to point to a list of writing techniques (as in, literature writing.) Can someone more knowledgeable than me give a better description of Journaling with respect to Filesystems and link to that? --RustB 03:30, 6 Mar 2005 (UTC)

This has already been fixed by someone. -- intgr 16:17, 26 June 2006 (UTC)

[edit] Further information

Does anyone know a good source for following the inclusing process of reiser4 into the kernel? Chotchki 00:14, 15 November 2005 (UTC)

KernelTrap or the Reiser Mailinglist http://blog.gmane.org/gmane.comp.file-systems.reiserfs.general --Hhielscher 00:21, 15 November 2005 (UTC)--Hhielscher 00:21, 15 November 2005 (UTC)


[edit] Stability

I've moved the following from the article.

Reiser4 is of very questionable stability at its current state. While the creators state they cannot make it crash any longer, there are still frequent reports of corruption and data loss. As with any new technology, avoid using in production.

The POV style of the text isn't really good, without some better citations I think we should leave it at the obvious.. the article already says that it's beta still and we really should leave it at that. --Gmaxwell 02:38, 22 November 2005 (UTC)

Wait -- beta? No, the article says it's not in the mainstream kernel and not really supported, which is true. It's also true that Namesys has officially "realeased" it, and encourages everyone to try it, while simultaneously warning that until millions of users have tested it, there will be obscure bugs not found in more mature filesystems. I actually agree with you in that it's beta or release candidate quality, by Linux standards, but by the standards of most commercial software, it's first-release quality. -- David Masover (not registered yet) —Preceding unsigned comment added by 69.18.2.149 (talk • contribs) 10:31, 5 January 2006

[edit] can "at the moment" be dated?

The second paragraph ends with "at the moment". I can't tell if this is true today, and in 5 years time I will really have no way to tell. Can someone state an approximation for when inclusion in Linux became the priority. 85.28.66.218 19:42, 6 January 2006 (UTC)

Well, you can tell by checking the diffs when the comment was added. I agree with what you are saying, though, "at the moment" is not clear to a casual reader. I think there is a wiki date format that allows it to change from, something like, "now" to "as of Dec. 25, 2005". Let me see if I can find it and I'll add it to the article. --- Markspace 23:24, 4 May 2006 (UTC)
You want [[As of 2006]] or the like... That way, the "as of" page will list this article as having assumptions that need to be rechecked later. Zuiram 10:55, 17 January 2007 (UTC)

[edit] Crypto/Compression

Reiser4 supports these through a "CryptCompress" plugin. The Article should updated. I don't know if it is included in the default distribution though. You can read more about it on namesys website -- Johannes Jordan —Preceding unsigned comment added by 131.188.30.63 (talk • contribs) 14:57, 9 May 2006

The reiser4 kernel patches do apparently include sources for the crypto and compression plugins, but as far as I know, there are no userland tools to instruct reiser4 to use these. It's probably already available from the (so far undocumented) libreiser4 library. I changed the entries to read "compile-time plugin" -- intgr 16:17, 26 June 2006 (UTC)
The Reiser4 cryptcompress plugin will be active when mounting the filesystem with the "reiser4.1-beta" mount option. -- intgr 19:02, 30 July 2006 (UTC)
It would be nice to specify in which versions of reiser4 this option is available 212.220.107.79 13:38, 9 September 2006 (UTC)
As he wrote: this option will not be available in Reiser4.0, but in Reiser4.1 --Hhielscher 16:32, 9 September 2006 (UTC)
Reiser4 in fact does support cryptcompress already, although I don't know in which stage (speak stability / readiness) it is, you can create cryptcompress partitions with reiser4 (v4 not v4.1-beta ?) with the recently released reiser4-progs 1.0.6 [1]
I'm running my GNU/Gentoo system on a partition with lzo1 compression & have my portage-tree on a gzip1-partition, for more information you might like to refer to ::::following thread: [2]
mkfs.reiser4 options are:
mkfs.reiser4 -o create=ccreg40,compress=gzip1 /dev/foo
mkfs.reiser4 -o create=ccreg40,compress=lzo1 /dev/foo
--Medwikier 12:31, 10 April 2007 (UTC)

[edit] Filesystem performance unimportant?

It is typically twice the performance of ext3 for general-purpose filesystem usage patterns, but since most real-world applications are not heavily utilising the filesystem, the performance improvements might not be noticeable.

I am quite dubious that "most" real-world applications do not heavily use the filesystem. Seeing that there's no citation, I'm removing that claim. Clement Cherlin 22:18, 26 June 2006 (UTC)

It should be fairly obvious that the average application rarely does more than open a few files and do straightforward reads/writes on them, with the bottleneck being speed of the CPU, hard drive, internet connection, etc. Heavy use, where filesystem performance really starts to matter, is when dealing with (hundreds of) thousands of files. That said, I guess the claim should be removed for now unless anyone can point to some real sources. -- intgr 07:59, 27 June 2006 (UTC)
In my experience, most tasks are either I/O bound (file system, network, etc.) or memory bound (memory bandwidth / latency). Usually they're disk I/O bound if you're serving a LAN, e.g. SQL server. This all varies widely, though, and it was a very encyclopaedic statement. Zuiram 10:57, 17 January 2007 (UTC)

[edit] Badly POV overview of controversy

On 14. July 2006, User:12.47.58.194 made the following edits to the article, which I removed for now:

Reiser4.0 is roughly twice the performance of competing filesystems, with users on the mailing list reporting that the Namesys benchmarks[3] roughly correspond to their real experiences. Reiser4.1-beta with its compress on flush to disk plugin roughly doubles that while reducing disk space usage by half --- at the cost of substantial CPU usage increases. Interestingly, due to its plugin architecture, you can switch between 4.0 and 4.1-beta using a mount option which simply changes what the default plugin is.

Not all filesystem benchmarks are conclusive. While I can agree that the Reiser4 filesystem is indeed faster than other filesystems in many circumstances (as I've been using it for months now), filesystem performance primarily depends on the usage pattern, fragmentation, etc. The "roughly twice" claim is clearly bullshit - it rarely happens outside of synthetic benchmarks. Also, most applications don't heavily stress filesystems and thus the performance increase will not be noticeable. All applications do, however benefit from a proven solid filesystem - given the number of issues ReiserFS had in the beginning, I'm not suprised that people are worried about Reiser4's reliability.

There have also been a number of benchmarks to claim the opposite, usually when dealing with larger files [4]. Many people have concerns about Reiser4's performance under fragmentation, and until Namesys releases their online repacker, this will remain an issue. -- intgr 10:24, 15 July 2006 (UTC)

The Reiser4 vs. ext3 rivalry is perhaps the most political issue in the Linux kernel. When Hans Reiser released benchmarks of ext3 vs. ReiserFS as ext3 was being first released, Ted Tso was deeply offended, and he was a Linux old timer with a lot of friends. When ReiserFS V3 was offered for inclusion into the mainline kernel, all emails from RedHat were opposed and all emails from SuSE (now Novell) were in support. The issues were ostensibly technical. When Reiser4 was offered for inclusion, the treatment it received was completely different from that received by the experimental ext4. Unfortunately, other Linux filesystems also receive such treatment, such as XFS which was delayed more than it should have been by the difficulty in getting some of its innovations into the core kernel, and lost key developers as they became discouraged from Linux. Many at first interested Linux filesystem contributors have simply walked away from Linux rather than deal with the lack of welcome to outsiders. Sadly, these political issues, reminiscent of BSD in the old days, are perhaps a good study of how not to manage free software projects that gain enough market share to for a while seem unassailable in their niche.

The writing style as well as the portrayal of people in thes second section above is highly POV, and cannot be acceptable for an encyclopedia. The editor also fails to refer to any sources at all regarding the claims made. The fact is that the primary issue for not merging the reiser4 filesystem remains coding style issues which Namesys has had plenty of time to fix. Hans Reiser's responses to criticism on the LKML have also been counterproductive at best, and have certainly won him a negative bias from other kernel developers. (for an example, [5], esp [6], there are plenty of more examples [7]). -- intgr 10:24, 15 July 2006 (UTC)

While I agree that had to go, I think this article has to be improved. It implies the reason Reiser4 is not in is because of coding issues. This is the claim of Linux kernel developers but it appears Hans Reiser claims otherwise and does allege political issues etc are the primary reason it is not in. The bit about ext4 vs Reiser4 has also been mentioned by Hans. As such, I think we need to mention these issues. It is not out job to decide whether the view of Linux kernel developers or Hans are correct. We should simply present them as neutrally as possible. It is up to the reader to decide which one to believe with the help of our references (and perhaps the fact that Hans Reiser has been arrested and charged with murder might influence their decision) Nil Einne 14:19, 11 October 2006 (UTC)
Absolutely, my problem with the preceeding edits was that it violated WP:NPOV much more than the original article [while admittedly, I am somewhat biased towards the Linux POV]. A neutral overview of the Reiser vs Linux controversy, from both points of view would be very much appreciated - it's already on the TODO list above, just noone has done it yet. And now that you mentioned it, I changed the coding style statement to make both points of view more clear; nevertheless, an extensive section on this is still needed.
It can be stated as fact that the decision thus far has not been influenced by the murder of Reiser's ex-wife, since the Reiser4 merging conflict has persisted for years, while Nina Reiser went missing on 03-09-2006.
For the record, Morton's Linux 2.6.19 merge plans currently state [8]:
reiser4. I was planning on merging this, but the batch_write/writev problem might wreck things, and I don't think the patches arising from my recent partial review have come through yet. So it's looking more like 2.6.20.
-- intgr 15:26, 11 October 2006 (UTC)

[edit] Hans Reiser arrest

Should we mention the future of Reiser4 is currently in doubt with the arrest of Hans Reiser? Nil Einne 14:21, 11 October 2006 (UTC)

I would say no – I don't think it will make a big difference. Namesys will probably still remain operational, with or without Hans Reiser. And as the Reiser4 code is GPLed, Linux developers are free to merge it without anyone's consent, once someone sorts the remaining issues out. As far as I can tell, comments from Hans Reiser himself often made the problems worse for the code review/merge of the filesystem. -- intgr 15:34, 11 October 2006 (UTC)
Alexander Lyamin from Namesys says that development on Reiser4 will continue [9]. -- intgr 19:53, 12 October 2006 (UTC)

Quite a point. Will Reiser4 ever be merged without Hans Reiser's strong efforts at getting it in, or will Reiser4 finally be merged now that developers dont need to worry about it being packaged with a Hans Reiser? :) -- 68.215.209.95 20:45, 25 October 2006 (UTC)


[edit] This section was removed. WHY?

Hans Reiser, a technical genius, is the main developer of the Reiser3 (ReiserFS) and Reiser4 filesystems. Reiser3 was an advanced filesystem, in its time, but is beginning to show its age. Reiser4, the replacement Reiser3, is truly cutting edge, an outstanding filesystem. To get some idea of how good Reiser4 really is, you should consider the following test results. The first column names the filesystem tested. The second column records the total time (in seconds) it took to run the filesystem benchmarking software bonnie++ (Version 1.93c). The third column records the total number of megabytes needed to store 655 megabytes of raw data. SMALLER is better.

FILESYSTEM TIME DISK USAGE
REISER4 (lzo) 1,938 278
REISER4 (gzip) 2,295 213
REISER4 3,462 692
EXT2 4,092 816
JFS 4,225 806
EXT4 4,408 816
EXT3 4,421 816
XFS 4,625 799
REISER3 6,178 793
FAT32 12,342 988
NTFS-3g >10,414 772


Each test was preformed 5 times and the average value recorded. SMALLER is better.

The bonnie++ tests were preformed, with the following parameters:

bonnie++ -n128:128k:0

More on the tests can be found here: http://m.domaindlx.com/LinuxHelp/resources/fs-benchmarks.htm

The above site provides a script, so that you can check these results for yourself.

—Preceding unsigned comment added by 219.88.158.100 (talk • contribs) 04:27, 22 March 2007

The obvious problem is that it's a copyright violation; in addition to that, file system performance is not limited to trivial operations like copying files and being done with it — degradation due to fragmentation have long been pointed out in ReiserFS and Reiser4.
In addition to that, Wikipedia is an encyclopedia — encyclopedias summarize existing research and knowledge, and do not present that research directly. See WP:NOT -- intgr 11:02, 22 March 2007 (UTC)
Also, an obvious violation of WP:NPOV. -- intgr 11:07, 22 March 2007 (UTC)
You obviously don't know Jack about filesystems. Pity an ignorant person like you gets any say at all. Bonnie++ is standard filesystem benchmarking software. The other tests, test extremely important filesystem operations like copying and how much space is wasted by filesystem inefficiency.
Degradation due to fragmentation, only occurs when the hard drive is essentially full (a not too common occurrence with todays large hard drives). A minor problem that may have a simple solution. Compared to Windows, the problem is non-existent.
Degradation due to fragmentation, is mainly a Windows filesystem problem, where it is so bad that it knowlegable people (not you) don't use Windows filesystems. —The preceding unsigned comment was added by 219.88.83.90 (talk)
I am not going to feed the trolls. -- intgr 08:10, 23 March 2007 (UTC)
If you want to know how fast it really is, just try it with a recent "stable" kernel (non mm-branch), e.g. viper-series, which can be found on gentoo-forums: [10] Benchmarking-results are just "theoretical" stuff, I think using it is the best way to create your own opinion (sorry I'm not a native-speaker). Always posting the same benchmarking results everywhere will only annoy people & prevent them from using / considering inclusion into kernel --Medwikier 12:38, 10 April 2007 (UTC))
Removed this again, per WP:OR and WP:NPOV. Reiser4 may be a great filesystem, but it's not the place of an encyclopedia to assert which is better or to publish benchmark results. Triona (talk) 23:54, 26 January 2008 (UTC)

[edit] Distributions

I didn't want to go ahead and remove an entire section without consulting first. Isn't it a bit silly, and leaning towards an add to say that The only distro to use R4 by default is thingy? Martijn Hoekstra 22:33, 22 April 2007 (UTC)

Looks out of place indeed. -- intgr 23:10, 22 April 2007 (UTC)

reiser4-alive: http://linuxhelp.150m.com/installs/compile-kernel.htm [11] —Preceding unsigned comment added by 91.65.134.248 (talk) 22:26, 19 February 2008 (UTC)