Talk:ReiserFS

Stubbing

As I had explained in the Reiser4 talk page, I also feel this page is very scant. Although ReiserFS is less advanced than Reiser4, it has many of the same complex principles (and great advantages) over ext2 and FAT32, but this article only skims over them. Therefore, if no one objects, I'll add stub status to this article. As I said, even the rather straight-forward FAT32 filesystem, which has severe disadvanatages to reiserfs, is far more detailed than this article. --Natalinasmpf 04:22, 23 Oct 2004 (UTC)

I totally agree. --Fredrik Orderud 23:55, 20 Apr 2005 (UTC)

The article also seems to be generously larded with FUD. I have been using ReiserFS on all my machines for more than 5 years and have never had anything go wrong. Recovering data fom ReiserFS partitions of failed drives posed no filesystem specific problems. Had ext3 been stable before Reiser I probably would never have started running Reiser, but I have never had any reason NOT to continue to run Reiser. —Preceding unsigned comment added by 131.215.115.31 (talk) 17:49, 2 November 2007 (UTC)[reply]

Is the link to Linuxmafia flamebait?

The "ReiserFS dangerous on commodity PC hardware" link to Theordore Tso's critique of ReiserFS journaling technique seems like flamebait. The link should be removed because it expresses an derogatory opinion without providing evidence that the incorrect behavior actually happens.

Regardless, the issue of block journaling commit policy is very technical and inappropriate for this article. Full treatment would be best given in another article. —Preceding unsigned comment added by 64.39.175.134 (talk • contribs) 03:51, 2 June 2005

I don't find it too bad, the link, but it is without much of any information to back the opinion up. It's just like you'd expect a BBS post on the topic. I'm definately not opposed to the link's removal. More opinions on this would be nice. -- Consumed Crustacean | Talk | 03:55, 2 Jun 2005 (UTC)

Put it that way: reiserfs was said to "eat data for breakfast". Bug reports over Bug reports came and most times Hans Reiser replied by telling the problem was no bug. This behaviour didn't help the users. Bug reports about dataloss especially wrong recovered or - at your choice - corruptet files after a crash with a journailed fs are severe as keeping data consistent is the whole point for journailing. It boils down to a simple fact: if you have a fs that leads to data loss while others don't and you are told that the problem will not even be looked at, the only thing you can do is to warn others about the problem. Maybe all problems solved now, but who knows? hans always told that and who dare to give it a try if the risk is lost data ... See, with other filesystems might be also dataloss but if so, a warning is sent out to the users. E.g. ext3 had dataloss problems - but they didn't hide them until they were fixed - that makes all the difference.

What's with the disadvantage section?

The majority of "Disadvantages" are quite obsolete, or simply nonissues.

"ReiserFS in versions of the Linux kernel before 2.4.10 is considered unstable by Namesys and is not recommended for production use, especially in conjunction with NFS."

Kernel 2.4.10 was released in September of 2001. At this time, there have been 21 updates to the 2.4 series since then. This issue is obsolete.

"Tail packing initially broke many bootloaders, which assumed file contents to be perfectly block-aligned. GRUB and LILO, two popular Linux bootloaders, have since gained support for reading tail-packed files. Tail-packing also imposed a significant performance penalty (because reads and writes for normally-contiguous files would have to seek to get to a tail packed elsewhere); Namesys recommends disabling the feature for performance-critical applications."

This states by itself that the problem is both obsolete and a nonissue; the bootloaders now have support for tail packing, and there has always been a way to turn it off.

"ReiserFS had no bad block handling prior to release 3.6.12."

Version 3.6.12 of ReiserFS was released in August of 2000. You'd have much difficulty finding somebody who uses it. This issue is obsolete.

"Converting a legacy ext2 filesystem to ReiserFS is also non-trivial and commonly requires a full dump and restore. ext3, in contrast, allows an in-place conversion."

I'd like to attack the use of the word 'legacy'. Making ext2 seem standard is misleading, because use of it is becoming rare as it is difficult to justify its use over the use of ext3. Also, ext2 and ext3 and practically the same thing; the only difference that I'm aware of is that ext3 is journalled. The fact that reiserfs can't convert from an entirely different filesystem is a nonissue; there isn't a filesystem out there that can.

To support my point: http://www.linuxquestions.org/questions/showthread.php?postid=1177376 Obviously a poll like this won't boast 100% reality, but it gives you an idea. --Laitment 20:24, 11 Jun 2005 (UTC)

I agree, the "disadvantages" section should be renamed to something that better describes the contents, eg, "Problems" or "Issues"? Or should it be split into two, as in problems with (1)earlier and (2)current versions? Ideas? -- intgr 11:59, 2 July 2006 (UTC)[reply]

ReiserFS as default fs for Linux distros...

One could argue that the wording may give an impression that those distros not listed may not support reiserfs by default or during install. Debian and Gentoo (and probably most of the up-to-date distros) definitely can format and install onto ReiserFS, and my experiences tells me many Gentoo installs meant for home uses tend to use ReiserFS. —Preceding unsigned comment added by Calyth (talk • contribs) 16:59, 9 August 2005

Debian can not create ReiserFS-filesystems during install. —Preceding unsigned comment added by 84.161.228.253 (talk • contribs) 23:35, 6 February 2006

Really? Surprises me since Ubuntu, which is based on Debian, can. —Preceding unsigned comment added by 88.217.2.112 (talk • contribs) 16:41, 2 April 2006

wrong. reiserfilesystem installers for debian existet at least since kernel 2.4.1.(that was 2001). nowadays debian uses initrd and you can allways use raiserfs with initrd. in the past debian didn't by default and installers that had reiserfs built as module didn't work as the modules themselves stored on that filsesystem - but as stated other installer had them built into the kernel. never the less, raiserfs was always considered dangerous...

Debian 6.0 installer doesn't support reiserfs by default. (You can do it by manually enabling installer plugin)

Doesn't Slackware use ext3 as it's default FS? Anyone has proof that Slackware uses ReiserFS as default? I know that it supports ext2, ext3 and reiser3 though, as shown by Comparison_of_Linux_distributions 86.139.202.10 21:57, 6 June 2006 (UTC)[reply]

The default for Slackware since at least version 9.1 (and probably earlier) was reiserfs. Starting with Slackware version 12.0, the default was changed to ext3. Patrick V. can probably verify with a quick email to a Slackware mailing list what version he started making reisferfs the default. 65.219.140.66 22:35, 27 August 2007 (UTC) Tom Lahti, Slackware subscriber.[reply]

Seems unclear

1) Tail packing, a scheme to reduce internal fragmentation. Tail packing, however, has a significant performance impact; Namesys recommends disabling the feature in performance-critical applications.

2) Compared to ext2 and ext3 in 2.4, when dealing with files under 4k and with tail packing enabled, ReiserFS is often faster by a factor of 10–15.

The conjunction of these two sentences seem rather unbelievable. Moreover, benchmarks do not seem to confirm the second one. 81.65.26.186 06:19, 14 March 2006 (UTC)[reply]

I guess it depends on whether you pack (a) a huge amount of tiny files, or (b) just the tails of larger files.

In case b, tail packing will probably slow you down significantly since without tail packing, files are more likely to be consecutive, resulting in less seeking and better readahead efficiency.

But in case a, when accessing a large number of tiny files, then packing means that the tails of the succeeding files might already be found in the disk cache from previous reads, thus resulting in fewer seeks and reads from the disk - and this is especially the case when most files are much smaller than the block size. It has also been said that ReiserFS shines when dealing with large amounts of directories and entries. An empirical example of these claims is the performance of the Gentoo Portage package management system.

I think the reasoning behind these cases should be pretty clear; I'm wondering why the developers haven't implemented a way to disable tail packing for larger files (since the space efficiency is negligible anyway). -- intgr 10:53, 14 June 2006 (UTC)[reply]

This is really very simple, and I believe it has been explained on the linked pages. In the (a) case, latency improves because you do not have to do an additional seek because the data is stored with the metadata (unlike for ext2), and bandwidth improves when accessing many small files with locality of reference due to increased density and readahead. In the (b) case, the slowing down is not at all related to sequential access (as metadata is generally kept in memory when the file data is resident, meaning the tail is in memory already from the time you open the file) but rather due to copying (the tiny file must be copied to a page of its own when read and copied back when written). The (b) case is, as pointed out, similar to what FFS experiences when growing a frag to a full block.

Reiser is hoping that we will eventually move to file systems where most of the "files" are about 10-100 bytes, which makes some sense, as few objects are larger than this; it's just a matter of turning the current collections of objects (files) into sets of objects. Paging hardware will make this difficult to do properly without a major paradigm shift, though.

Zuiram 10:53, 17 January 2007 (UTC)[reply]

lsattr and chattr

One should write there about incompability with ext2/3, which disallow user to use extented attributes of files. (like append-only, etc) It's a big disadvantage of ReiserFS.

openSUSE talking about dropping Reiser

openSUSE (perhaps SUSE Linux too?) is probably dropping ReiserFS as its default file system. [1] --Spug 22:44, 3 October 2006 (UTC)[reply]

The linked mail seems to be just a proposal, this isn't time to even discuss it on WP. Gronky 11:37, 4 October 2006 (UTC)[reply]

If it was was a proposal it became fact. The default filesystem in openSUSE 10.2 is ext3 (but you still have the choice to use reiserfs). 81.96.206.228 16:57, 4 February 2007 (UTC)[reply]

As the author of the proposal, the link between Hans Reiser's arrest and the proposed change to the openSUSE default file system is entirely misleading. As a point of fact, I actually found out about Hans's arrest several hours after I sent the email, and the topic itself had been under discussion internally for a while before. Also, the default only applies to openSUSE, not SUSE Linux Enterprise as noted in the article. JeffMahoney 21:22, 8 August 2007 (UTC)[reply]

Max filename length

The table says the maximum filename length is "4032 bytes/255 characters"

This doesn't make any sense; 255 characters would be 255 bytes, or 510 if using Unicode. Which is correct? Or does it mean bits -- but that would be 4080? 134.53.26.79 15:46, 22 February 2007 (UTC)[reply]

Indeed, that's dubious. -- intgr 08:27, 23 February 2007 (UTC)[reply]

255 bytes is incorrect here - it's actually blocksize - 64 bytes, which is normally 4032 bytes -- SaguratuS 08:47, 5 June 2007 (UTC)[reply]

The disk format supports blocksize - 64 bytes, but the Linux VFS imposes a 255 character limit on path components. -- JeffMahoney 21:21, 8 August 2007 (UTC)[reply]

Redirect from "MurderFS" to "ReiserFS"

whoever created this link is just plain respectless, Hans deserves the right to be treated as innocent until proven the opposite (seemingly the prosecution has a hard time to do so ;) - that's a really strange case ...) so could anyone with "admin"-rights please block the entry "MurderFS" from being redirected to this entry in the future and/or prevent any associations being made with the murder (case) and Hans' filesystems (there simply isn't any) ? many thanks in advance --Medwikier (talk) 19:34, 8 March 2008 (UTC)[reply]

I just saw that it was removed, thanks a lot ! --Medwikier (talk) 11:49, 5 April 2008 (UTC)[reply]

Unfortunately the link is still there. I just searched for murderfs and it redirects here. (June 10th 2008)

Inserting link here for convenience:

if is(link, blue) then { delete(MurderFS); }

Sir June-10, don't forget to sign by inserting tilde*4: ~~~~! ... said: Rursus (^mbork³) 11:00, 25 October 2009 (UTC)[reply]

Murder conviction

There seems to be a significant group of people who feel that Reiser's status as a convicted murderer is pertinent to the article. Another body seems to feel that this is interesting, but completely irrelevant. Should it be included, or should it only be discussed if it is shown to have affected adoption of the FS. Your thoughts? 207.164.21.130 (talk) 01:49, 3 May 2008 (UTC)[reply]

"designed and implemented by a team at Namesys led by convicted murderer [1] Hans Reiser." - This makes it sound like the murder happened before the filesystem. It doesn't belong in the lead paragraph. —Preceding unsigned comment added by 138.87.186.107 (talk) 02:19, 3 May 2008 (UTC)[reply]

Agreed. The question is whether it belongs at all. 207.164.21.130 (talk) 03:12, 3 May 2008 (UTC)[reply]

The right thing to do here is to not mention it as if the conviction predated all the Reiser FSs, nor to mention it in the lead; but only mention it if it affects the filesystem. As ReiserFS (the first one) was completed long before Nina disapeared, and IIRC is considered in maintenance, his murder conviction has little relevance. Now, I know I've seen some RS articles speculating about how the murder conviction impacts Reiser4's development, and that article should definitely include a section on 'Future Development' or something. That article is not this article, however. --Gwern (contribs) 03:41 3 May 2008 (GMT)

While the development of ReiserFS is irrelevant to the fact that its creator is a convicted murderer, given the sensational and despicable nature of the crime, I believe associating the crime to the creator is relevant. There is a moral obligation to any action we take, and alerting potential users of Hans Reiser's crime allows them to make an informed decision.

There is also a practical side to mentioning Reiser's crime: you do not want to describe what a wonderful product ReiserFS is without realizing its creator killed his wife. Swfong (talk) 21:10, 3 August 2008 (UTC)[reply]

I agree with the preceding argument (previous 2 paragraphs). In addition to this, the article in its current state makes a passing reference to a 'murder charge' without going any further, which may give the impression that that's all that came of it. I think that is misleading; while we do not need every fine detail about the murder case, if we are going to mention the murder at all we should at least admit that he is, in fact, a convicted murderer and perhaps link off to the main Hans Reiser article for more information. mmj (talk) 05:33, 19 December 2008 (UTC)[reply]

There is also the question of how this will affect future development of the filesystem - I came here while searching around to see if Reiser might have had the decency to consent to changing the name of the FS, and if not, how future development of the filesystem would be affected. Seems silly not to mention that the guy who the filesystem is named after committed a pretty high-profile murder. —Preceding unsigned comment added by 216.13.132.178 (talk) 00:17, 13 January 2009 (UTC)[reply]

While a murder is a terrible awful thing, it does not take away from the fact that this may be very useful technology. Someone should at least fork the code, under a new name. Perhaps a "murder controversy" section could be added later, to note that Hans Reiser has been convicted but that this does not detract from what may be great technology. 81.100.182.131 (talk) 00:22, 15 January 2009 (UTC)[reply]

I added the fact that he was convicted; the placement probably ain't the greatest, but I didn't want to spend twenty minutes working out the best place the put it(I did, however, give some thought to the wording to prevent any association betwixt the conviction and the "did they drop it because of what happened?" thing). BioTube (talk) 00:50, 26 February 2009 (UTC)[reply]

stop linking to convertfs

In the 'external links' section there is a link to convertfs. I suggest this link to be removed. convertfs is completely unrelated to the article and the ReiserFS filesystem. It's a proof of concept of a great idea that allows you to convert any filesystem to any other filesystem in place (and resizing it while you're at it). However the implementation is so bug ridden that you're not likely to see your data again soon. It's unmaintained since 2002 (except for a minor fix 2005 contributed by someone else) and never got past its proof-of-concept stage. Because it's buggy and unmaintained, most Linux distros have kicked it out of their repositories by now. —Preceding unsigned comment added by 87.178.71.238 (talk) 21:59, 28 June 2008 (UTC)[reply]

Link to Reiser4 description

On the bottom of the page, it says: "Namesys web site is now offline but try a cached version of the Reiser4 description (without figures)." The Google cache is gone, so I suggest a link to that page at Archive.org instead. --82.171.70.54 (talk) 20:33, 7 August 2008 (UTC)[reply]

Article protection

I can only view the source, which seems to indicate this article is protected. Why isn't a lock image being shown automatically in the top right corner? (I mean one of these.) --82.171.70.54 (talk) 20:37, 7 August 2008 (UTC)[reply]

Okay, the protection seems to be gone now. --82.171.70.54 (talk) 11:42, 2 September 2008 (UTC)[reply]

Performance (not NPOV!)

The paragraph about ReiserFS' performance is not neutral. It ignores one major benefit, and relativizes another in a non-neutral way:

ReiserFS does not require a file-system check on start-up. On today's harddisks this check can easily take 30 minutes. ReiserFS does not need it, and in conjunction with its full journalling, this feature (still!) makes ReiserFS the ideal choice for all systems that re-boot frequently like laptops.

ReiserFS outperforms everything else - including XFS, leave alone ext3 - available on the Linux market, when it comes to handling of a lot of small files. Both ext2 and ext3 get outperformed by everything else available on the Linux market unless you deal with extremely large files. The article incorrectly justifies this discrepancy by stating that ReiserFS' advantages in this sector are "nullified" by a mysterious feature called "cycbuf" (the search term "cycbuf" currently triggers 722 hits on Google).

In practice - and contrary to what the article says - you have two choices when dealing with large quantities of data sets: You either rely on a well-tuned file system or you use a Relational database system. If you decide for a database, all serious databases offer options to organize data in raw device files, completely bypassing the file-system. Performance on very large files is irrelevant today, and even in this area ReiserFS is not a failure; it is just on eye-level with its competitors. The supposed "cycbuf" approach is just a workaround for file systems that croak on many small files.

The link in the criticism about usage of the Big Kernel Lock currently leads to la-la-land; not without reason. ReiserFS enforces file system integrity at run-time. This is why it can make do without a file system check at start-up.

A fair evaluation of ReiserFS would state under "Performance" that it is the leader of the pack for many small files, for laptops, and still acceptable everywhere else. If you criticize it, then please add real proof.

--GFlohr (talk) 17:56, 17 August 2009 (UTC)[reply]

I edited relativates as I hope yoi meant it, Jabberwoch (talk)

oh yeah, and btw, the guy who was in charge of it is in prison for life for murder

and the company is no longer engaging in commercial activity.

im assuming that uhm.. that might be worth mentioning in an encyclopedia article... simply because many 'secondary sources' have written articles pondering what will happen to the project since its former leader can no longer lead it or contribute to it, and obviously many customers are wondering the same thing (and im wagering that if you dig around you can probably find articles about the customer's questions as well). I personally am probably not going to touch it because of the wikipedia:wikistress involved.

Example: article by Justin Mann, http://www.techspot.com/news/23188-the-future-of-namesys-and-reiserfs.html, 2006, "says Oleg Drokin, the former release manager at Namesys. "If he is convicted, that might cause problems for Namesys [because] it is operated solely by Hans.""

Decora (talk) 06:44, 23 August 2009 (UTC)[reply]

ohhhh.. i see what happened ( i guess? ). the article did used to mention it, sort of. then someone deleted this mention because it was 'unrelated to the filesystem' and was 'gossip'. ...... i dont really agree with that.... however..... the part this person deleted itself had several problems, including:

1. the citation lacked a proper title and author (there is no article at that link named ""Announcement was unrelated to Reiser's legal troubles" written by Jeff Mahoney or anyone else. . Mahoney did wrote a comment on a blog post, in october, that was about a proposal he had made in september, of 2006, mentioning the 'legal trouble', i assume that was what the original author had intentioned to link to....)

2. the article text said that 'suse claimed the switch was unrelated'. Mahoney had an email address at suse.com, but he specfically states on that page of comments that he did not speak for SuSE or Novell(nor would one expect an posting on a public blog comment section to be considered as speaking for a company). also, he specificalyl says his email was not an announcement, it was a proposal

2.5 the article text had date problems. it said 'two days before' the announcement by novell, 'suse' had said it was 'unrelated' to reisers 'legal problems'. actually the link says the announcement was made on thursday, which would have been october 12, which is 8 days later than oct 4, which is the day listed on the comment Mahoney made on the blog that the citation linked to, not two days.

3. the citation had a url that was a dead link to linux.wordpress.com, that was broken and/or unavailable. i found the original text using archive.org.

perhaps there is some other article out there, that mentions the things the article text said, authored by who it said authored it, referring to things that happened on dates it says they happened on... but the url provided is not it, the title isnt it, the author doesnt match, and there is no obvious article that would be a candidate for the 'missing article'. so... i tried to fix it up a little and fix some of these problems.. i kept the citation link, and add a little note in the 'ref' section describing what it is, and tried to provide proper title, archiveurl, url, dates, etc. i put it in the 'ref' section because i couldnt figure out how to fit it into the main article without writing an entire section on the suse switchover, but i dont feel like doing that major of a change. guess time will tell how i did. Decora (talk) 08:25, 23 August 2009 (UTC)[reply]

ok.. i .. felt like there was no 'right way' to do this other than to add a section about novell switching to ext3. i mean, the original editor linked to some important stuff, it was just described wrong and cited wrong, (or linked wrong? is there some missing article that backs up the original article text?). so i tried to link to the same thing the original editor linked to.. , but to rewrite the description of what was linked to. i.e., that Mahoney of Suse specifically says he is worried about people connecting Reiser's "legal trouble" with the switch to ext3, then that he specifically states it is not a reason for the switch, and he also lists a bunch of technical reasons for the switch. hope i did ok.... Decora (talk) 09:16, 23 August 2009 (UTC)[reply]

Looks good to me, thank you for your efforts! -- intgr [talk] 08:02, 24 August 2009 (UTC)[reply]

External links modified

Hello fellow Wikipedians,

I have just modified 9 external links on ReiserFS. 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/20060614084322/http://www.namesys.com/X0reiserfs.html to http://namesys.com/X0reiserfs.html
Added archive https://web.archive.org/web/20060705190506/http://www.namesys.com/faq.html to http://namesys.com/faq.html
Added archive https://web.archive.org/web/20071024001500/http://www.namesys.com/v4/v4.html to http://www.namesys.com/v4/v4.html
Corrected formatting/usage for http://cbs5.com/topstories/local_story_256204954.html
Added archive https://web.archive.org/web/20071024001500/http://www.namesys.com/v4/v4.html to http://www.namesys.com/v4/v4.html
Added archive https://web.archive.org/web/20050210042704/http://linuxmafia.com/faq/Filesystems/reiserfs.html to http://www.linuxmafia.com/faq/Filesystems/reiserfs.html
Added archive https://web.archive.org/web/20050509002339/http://p-nand-q.com/download/rfstool/reiserfs_docs.html to http://p-nand-q.com/download/rfstool/reiserfs_docs.html
Added archive https://web.archive.org/web/20071114053341/http://p-nand-q.com/e/reiserfs.html to http://p-nand-q.com/e/reiserfs.html
Added archive https://web.archive.org/web/20120111062641/http://www.crossmeta.org/redmine to http://www.crossmeta.org/redmine

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) 00:17, 3 December 2017 (UTC)[reply]