Talk:ReiserFS

From Wikipedia, the free encyclopedia

Contents

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

[edit] 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.

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

[edit] 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...

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)

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.

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

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)
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)

[edit] 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.

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

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)
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)
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)

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

Indeed, that's dubious. -- intgr 08:27, 23 February 2007 (UTC)
255 bytes is incorrect here - it's actually blocksize - 64 bytes, which is normally 4032 bytes -- SaguratuS 08:47, 5 June 2007 (UTC)
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)

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

I just saw that it was removed, thanks a lot ! --Medwikier (talk) 11:49, 5 April 2008 (UTC)
Unfortunately the link is still there. I just searched for murderfs and it redirects here. (June 10th 2008)

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

"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)

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

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)