Talk:Reiser4

This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Linux Low‑importance This article is within the scope of WikiProject Linux, a collaborative effort to improve the coverage of Linux on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.LinuxWikipedia:WikiProject LinuxTemplate:WikiProject LinuxLinux articles Low This article has been rated as Low-importance on the project's importance scale. Computing: Software / Free and open-source software Low‑importance This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles Low This article has been rated as Low-importance on the project's importance scale. This article is supported by WikiProject Software (assessed as Low-importance). This article is supported by Free and open-source software (assessed as Low-importance).

To-do list for Reiser4: edit · history · watch · refresh · Updated 2006-10-01 Here are some tasks awaiting attention: Article requests : * Overview of the Hans Reiser vs. Linux kernel team controversy More information about the cryptcompress plugin

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)[reply]

Problem solved. AlistairMcMillan 01:21, 5 May 2006 (UTC)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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

I'm surprised there's no mention of filesystem operations being atomic. It proved quite an amazing stability feature when using a defective motherboard and a lot of system crashes. 98.156.97.208 (talk) 00:20, 14 November 2009 (UTC)[reply]

File operations are atomic as specified in POSIX standards in every journalling Linux file system. Maybe you are confused by the fact that Reiser4 was going to export some sort of API for transactions, but that never happened. -- intgr [talk] 13:35, 14 November 2009 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

As he wrote: this option will not be available in Reiser4.0, but in Reiser4.1 --Hhielscher 16:32, 9 September 2006 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Alexander Lyamin from Namesys says that development on Reiser4 will continue [9]. -- intgr 19:53, 12 October 2006 (UTC)[reply]

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)[reply]

Well a long time later and I wrote the above with limited experience with wikipedia and BLP (which was less than a year old). Clearly there should have been no comment on Hans Reiser's arrest in relation to Reiser4 without good sourcing. That said while hindsight is 20-20, it looks like I was mostly right. From what I can tell Reiser4 is still out of the Linux kernel and seems to be in some sort of no man's land. btrfs is probably the best alternative (I've read some suggesting it's overtaken Reiser4 by now), and maybe ZFS for those not bothered by licencing concerns (or for those outside the Linux world). Of course we can never know what would have happened if Hans Reiser hadn't done what he did, the IP has a point that perhaps he wasn't a help in many ways. But at the same time, actually having a company behind it would likely have helped. While Intgr was right, it was theoretically possible for Namesys to survive, it didn't. I don't think this is that surprising since while I know little about them, it sounds like they were in many ways Hans Reiser's company and further the main thing the company did was develop ReiserFS and Reiser4. In particular, I assume they offered paid support for those file systems and their users. Even if they had the management team etc to survive the arrest and any sale, buying a company from someone accused of murdering their wife, and where the company's primary new product is a file system still not in the Linux kernel and with no clear prospective for it being in, named after said person accused of murdering their wife and where their old product had just been abandoned by one of the only significant users and likewise was named after said person, doesn't sound that appealing. I also wonder whether some of the developers both those who worked for Namesys and those for other companies and independently, were some demoralised by what happened. (Especially those who worked for Namesys, since it sounds a bit like why weren't surprised by the arrest and may have also expected the eventual outcome. Also from what I've read, quite a few of them were in Russia which may not have helped.) I can't help wondering if it was also a factor in the development of btrfs, although OTOH, even without Reiser doing what he did, it doesn't sound like he was the easiest person to work with. Nil Einne (talk) 19:34, 6 February 2019 (UTC)[reply]

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://linuxhelp.150m.com/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)[reply]

Also, an obvious violation of WP:NPOV. -- intgr 11:07, 22 March 2007 (UTC)[reply]

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)[reply]

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))[reply]

Then don’t feed yourself and starve and hence shut up. Problem solved. … Funny how crazy people always call everyone not obeying their insane views a “troll” when they happen to become the ones in power. Philosophical protip: Just because you got the biggest club doesn’t make you right. No matter how much Wikipedia is designed to enable (yet disguise for purposes of being able to argue the opposite to clueless people) that kind of totalitarian dictatorship. -- Evi1M4chine (2A0A:A546:A8E:1:C27C:C014:A0D8:FCC3 (talk) 14:49, 15 April 2023 (UTC))[reply]

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)[reply]

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)[reply]

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

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)[reply]

The citation of http://www.phoronix.com/forums/showthread.php?t=9509 is incorrect, first of all, because the original source of that forum post is located here: http://linuxhelp.150m.com/. And second of all, I challenge the citation because the source is very questionable. The person who wrote that page has made multiple unfounded accusations and assertions on his page that themselves really need citation. For instance, after displaying some benchmarks of Reiser4 vs other filesystems, he states in red text (for emphasis), "As you can see, REISER4 is a truly remarkable filesystem. This is the real reason that REISER4 has not been included in the Linux kernel. This is the real reason that Hans Reiser languishes in an Oakland prison cell at this time." I am not convinced this person is mentally stable, and that this citation should be changed to point to a more reliable and accurate source. Neunon (talk) 04:31, 14 June 2008 (UTC)[reply]

Do you think it is necessary to mention in _this_ article that he killed his wife? I think it is background information about the creator, and not really belongs in here. What's your opinion? -- Keks ger (talk) 21:41, 26 July 2008 (UTC)[reply]

I took out the "murderer" bit in the lead. That was rather irrelevant and over-the-top (and it was just added today). It's still mentioned in the "Future of ReiserFS" section, but that seems relevant, at least to me, since he was the main architect of the filesystem, and, being imprisoned, he can no longer work on it, which is why the future of the filesystem is up in the air. --Slowking Man (talk) 23:59, 26 July 2008 (UTC)[reply]

Following some talk on lkml.org, I got the impression, that Edward Shishkin seems to be the guy, who heads all decisions. Should we actually name him the new maintainer of the Reiser4 file system in the article? —Preceding unsigned comment added by 88.73.142.216 (talk) 12:26, 9 April 2009 (UTC)[reply]

Hello fellow Wikipedians,

I have just modified one external link on Reiser4. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Corrected formatting/usage for http://www.namesys.com/

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 18:49, 31 March 2016 (UTC)[reply]

Hello fellow Wikipedians,

I have just modified 4 external links on Reiser4. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20100324124748/http://chichkin_i.zelnet.ru/namesys/ to http://chichkin_i.zelnet.ru/namesys/
• Corrected formatting/usage for http://linuxhelp.150m.com/installs/compile-kernel.htm
• Corrected formatting/usage for http://linuxhelp.150m.com/installs/install-on-reiser4.htm
• Corrected formatting/usage for http://www.namesys.com/v4/v4.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 05:00, 11 December 2017 (UTC)[reply]