It appears that the Reiser filesystem is somewhat of an orphan child in the Linux Kernel. See, for example, http://linux.wordpress.com/2006/09/27/suse-102-ditching-reiserfs-as-it-default-fs/ for a summary of technical and maintenance problems with it. I recently had kernel crash due to the ReiserFS bug documented at http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6d205f120547043de663315698dcf5f0eaa31b5c (fixed in 2.6.21) with filesystem corruption on a reiserfs partition on one of my production servers which I reported on Gentoo Bugzilla. See Daniel Drake's comments on it at http://bugs.gentoo.org/show_bug.cgi?id=179563#c6 and his observiations on the Reiser FS. I've heard similar comments from others as well, and apparently development of the Reiser FS has been fairly moribund since it's inception in Linux. Nonetheless, the Gentoo Handbook (http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1&chap=4#doc_chap4) gives the Reiser filesystem a pretty glowing recommendation. Perhaps this should be re-examined. I used ReiserFS on my servers because of this recommendation, but if I knew then what I know now I'd have used ext3 instead.
It's no more or less glowing than the other FSes that we cover. Reiser won't be un-recommended (if that's a word) anytime soon, regardless of what crappy distros like SUSE do. Reiserfs is better than ext3 particularly for the Portage tree, which as you know consists of lots of tiny files; just the sort of thing reiser excels at. It works just fine; the only problem I've ever had in two years of use on multiple machines was a user error, not something the filesystem ever did. You'll hear similar testimonials all over, so until there are a lot of press releases from Namesys saying it won't be developed or from kernel devs saying they're kicking it out entirely, the handbook should be kept as it is. I'll keep your links in mind though; thanks for mentioning them. I'll have to poke DSD as well for more of an inside track on the kernel side of the issue.
(In reply to comment #1) > It's no more or less glowing than the other FSes that we cover. Well, if I was a user that knows nothing and has zero experience, I'd select reiserfs based on the HB recommendations. In fact, I did so years ago when I started using Gentoo. It could be because I'm not a native speaker, but it's the impression HB made (and makes) for me. > Reiserfs is better than ext3 particularly for the Portage tree, which as you > know consists of lots of tiny files; just the sort of thing reiser excels at. I guess we all can agree that ext3 sucks in this area, but don't forget ReiserFS is not the only FS that does it well. > You'll hear similar testimonials all over I'm sure one can find a lot of "oh no, $first FS ate all my data, I've never seen that with $second FS" claims where one can substitute anything for both $first and $second. > so until there are a lot of press > releases from Namesys saying it won't be developed or from kernel devs saying > they're kicking it out entirely, the handbook should be kept as it is. If the HB didn't recommend it (although not explicitly), I'd agree, but it's true that we kind of recommend reiserfs.
(In reply to comment #1) > Reiserfs is better than ext3 particularly for the Portage tree, which as you > know consists of lots of tiny files; just the sort of thing reiser excels at. Do you have recent numbers to back this up? Numbers that weren't generated from unfair/unrealistic tests which would be benchmarking a perfectly balanced tree on the reiserfs partition... I think you'll be pleasantly surprised. > It works just fine; the only problem I've ever had in two years of use on > multiple machines was a user error, You can't base this judgement on personal experience. We have thousands of users. Sure, reiserfs must be pretty damn good because there are only a handful of real bug reports over time. Importance of filesystem reliability aside, it's a nice achievement to have such a high success rate for a large body of code. That said, there's no doubt that we have seen more reiserfs bugs than other filesystems over time. You can't read too much from this result though - we might well have proportionally more reiserfs users than other filesystems. The disturbing part is that even if such bugs are rare, we're talking data storage here, and it often takes years for such bugs to be fixed in reiserfs. Many reports are not even analysed by developers and just sit around. I've never seen this be the case for my filesystem of personal choice, ext3, except for one really obscure bug involving exceptionally large partitions (which was fixed in a matter of months). > You'll hear similar testimonials all over, so until there are a lot of press > releases from Namesys saying it won't be developed or from kernel devs saying > they're kicking it out entirely, the handbook should be kept as it is. Hold up on that for a minute. The story goes something like this: - reiserfs was developed - The developers hyped it up a hell of a lot - The developers argued for kernel inclusion - Kernel developers pointed out a few moderately serious issues - After kickback from developers, it was agreed that reiserfs could be included before the issues were resolved - reiserfs got included in the kernel - The developers went pretty much silent, and didn't address the previously raised issues - The extra testing revealed a few serious data-corrupting issues - nothing really happened, time passed - some of the issues got fixed over a year or 2, by a mix of namesys and non-namesys developers And that's really the whole story -- reiserfs hasn't really gone anywhere since inclusion, except for being fixed up in part. This situation is actually repeating itself - reiser4 is being argued for inclusion, kernel developers have pointed out some issues, reiser4 developers are arguing for inclusion anyway ("we'll fix it later"), but this time it won't be included in such an early stage. As for the present day state of reiserfs development: over the last 2 years, namesys have contributed only SIX patches to reiserfs. The primary "developers" of this filesystem both work for SuSE - a distro who don't even ship the filesystem by default anymore! Over the same time period, SuSE have contributed 29 patches. Of the 35 patches mentioned above, a significant proportion of them are fixes for serious bugs such as corruption and panics. Hardly any of them are performance/feature improvements, meaning that the bug fixes are fixes for long term bugs that have existed since reiserfs was created several years ago... For what it's worth, when I started using Gentoo several years ago, I also interpreted the handbook as a recommendation for reiserfs and chose it for my root filesystem. However I changed shortly after once I discovered the vast range of recovery and maintenance options for ext3.
Um. So does that mean you support a less glowing recommendation? FWIW I have used reiser exclusively for years, and then i read http://zork.net/~nick/mail/why-reiserfs-is-teh-sukc as well as other stuff. I only changed however, when I got random data in a script file I was developing which was run via symlink. It also made me wonder about all the glitches I had blamed on buggy software.. In any case, I still use it for portage tree (distfiles is another partition), and I support a downgrade in recommendation based on my experience, and the comments /links already posted. I really would never advise use of reiser on anything critical at all. (The portage tree can of course be resynced at any time, and has signatures for all files.)
(In reply to comment #4) > Um. So does that mean you support a less glowing recommendation? Yes.
Er is it possible to change this to NEED_PATCH then?
(In reply to comment #6) > Er is it possible to change this to NEED_PATCH then? > Nope, the handbook won't be changed.
(In reply to comment #7) > Nope, the handbook won't be changed. If the reason is "I don't want to do that", there are other GDP members (/me waves). At least one native speaker and member of kernel team is in favor of change...
Well it's entirely your call of course, no-one can force you to change it. My concern is that users continue to extol its virtues on the forums and on irc; if their files do anything like what I saw, there will have been numerous glitches which have been misdiagnosed or (more likely) just ignored, despite being filed as bugs. After all, no-one would ever consider that the filesystem might be providing random data. These problems will have consequent effects on users, even more so when no solution beyond "upgrade" is found, since they will then wrongly blame the issue on Gentoo software, as opposed to reiserFS which has such a l337 image, perhaps all the more so since it is not recommended for Enterprise use. "for a filesystem, performance is Job #2. Making sure you don't lose data is Job #1." As for not doing what Suse does, did it not occur to you that they have paid engineers assessing and benchmarking solutions? /me votes to recommend reiser for /usr/portage only. (Er I'd also advise users to have a separate /home in case of reinstall.)
We have a mention that files can disappear from XFS in the same section where the description of ReiserFS is. Why not add about ReiserFS that it's not for people who want high reliability of their file system and write we suggest ext3 for new users as we don't want to take responsibility for their system breaking randomly? Something like "Lack of real journalling on ReiserFS can cause your file system to break on unexpected power down so it's not suggested for people who want their system to be very reliable." Also i'd add a sentence to the ext3's description: "If you are not sure which file system to choose for your installation, go for ext3 for it's extreme reliability and good performance." What do you think?
(In reply to comment #10) > We have a mention that files can disappear from XFS in the same section where > the description of ReiserFS is. > > Why not add about ReiserFS that it's not for people who want high reliability > of their file system and write we suggest ext3 for new users as we don't want > to take responsibility for their system breaking randomly? Because that's silly. ReiserFS is just as reliable as any of the other journaled filesystems out there. In fact, it's arguable that it's more reliable than XFS in particular, seeing as the latter is more likely to hose your system on a power outage since it aggressively caches everything in main memory. > Something like "Lack of real journalling on ReiserFS can cause your file system > to break on unexpected power down so it's not suggested for people who want > their system to be very reliable." This simply isn't true, though. > Also i'd add a sentence to the ext3's description: "If you are not sure which > file system to choose for your installation, go for ext3 for it's extreme > reliability and good performance." > > What do you think? I disagree with this, too -- ReiserFS and ext3 are just about equal with each other; ReiserFS can exceed performance of ext3 in some cases, even. This is sort of like that first ALSA bug we got from Diego -- the *most* we should do is reexamine the wording to make them equal to each other. I still believe ReiserFS is superior to ext3, especially on Gentoo, given the nature and layout of the kinds of files installed.
I did a bunch of reading on various filesystems after this accident, and it looks as if this is one of those issues that people will argue about endlessly. The bottom line, however, seems to be that ReiserFS, unlike ext3, is not supported by a substantial community of developers (I believe one person is still on top of it) and that there are issues going forward, related to this lack of support, that may render it obsolete at some point. Hans Reiser's attention these days is doubtless consumed by his upcoming trial. Ext3, on the other hand, is under active development with an easy upgrade path to the still experimental ext4 filesystem. I've got my fingers crossed that upgrading to kernel version 2.6.21 (which apparently addresses the problem I had) will render my ReiserFS installations more stable, but the fact remains that it appears to be not as widely supported as ext3 and that problems of this nature have cropped up before. Benchmark tests give ReiserFS (as well as XFS and JFS) a substantial speed edge over ext3. Like the tortoise and the hare, ext3 seems to be solid, albeit slower, whereas ReiserFS, like the hare, is fast but more susceptible to being eaten by a random hawk.
(In reply to comment #11) > Because that's silly. ReiserFS is just as reliable as any of the other > journaled filesystems out there. In fact, it's arguable that it's more reliable > than XFS in particular, seeing as the latter is more likely to hose your system > on a power outage since it aggressively caches everything in main memory. Could you please provide another source for the "XFS aggresively caches everything in main memory" statement than our handbook? > > Something like "Lack of real journalling on ReiserFS can cause your file system > > to break on unexpected power down so it's not suggested for people who want > > their system to be very reliable." > > This simply isn't true, though. This could be true, depending on how you interpret "real data journaling". As none of XFS/Reiserfs does file *data* journaling and ext3 can be asked to do so, that sentence might be true. > I disagree with this, too -- ReiserFS and ext3 are just about equal with each > other; ReiserFS can exceed performance of ext3 in some cases, even. ...as well as can JFS and XFS or $insert_your_favourite_one_here.
(In reply to comment #10) > Why not add about ReiserFS that it's not for people who want high reliability of their file system and write we suggest ext3 for new users as we don't want to take responsibility for their system breaking randomly? > > Something like "Lack of real journalling on ReiserFS can cause your file system to break on unexpected power down so it's not suggested for people who want their system to be very reliable." > I'd use the term "physical journalling" instead of "real journalling" since that is where the issue lies on PC-class hardware. Note that it's not just power outage that can make it fail, random data has happened to me on numerous occasions although I have no idea why; I just know that it doesn't happen with ext3. I heard there was an issue with filenames, but I am not about to debug it any time this century :-) > Also i'd add a sentence to the ext3's description: "If you are not sure which file system to choose for your installation, go for ext3 for it's extreme reliability and good performance." > > What do you think? All of those sound good to me. I'd also stress the use of a separate /home as well, because of IRC users I've helped who have no simple reinstall plan. As for reiser being equal or superior, I find it odd that since I switched to ext3 I have had zero data loss, except for one burst of random data on yes, the reiser partition (/usr/portage.) I am back to using a symlink to develop my script and the garbage simply never appears, when it was a fairly frequent occurrence with reiser. As I said, portage files are checked via signatures and a simple sync resolved the issue; nothing of the sort happens on other parts of the filesystem so I really think we need to think about Job #1 - preserving user data. igli - bitten by experience, but still into the whole journalling thing :-)
I agree we should tone down the reiserfs description and not recommend it for any data you'd like to keep. I'll change that part only once, which means it'll have to wait a bit more until it goes into an included snippet.
(In reply to comment #15) > I agree we should tone down the reiserfs description and not recommend it for > any data you'd like to keep. Thanks. > I'll change that part only once, which means it'll have to wait a bit more > until it goes into an included snippet. > Er once in how long?
I think there's lots of talk about reiserfs. Imo, Gentoo's kernel team has the final saying on this.
Speaking from working on kernel bugs for a long while: We've only had a couple of ext2/3 bugs over the last few years: - a strange problem with huge volumes (petabyte size), fixed - a harmless trace being printed after you mount the filesystem under windows using the ext2 driver there (being worked on) We have had reiserfs bugs, resulting in data corruption/freezes/... Only occasionally, but they have been there. So, what I would suggest is that ext3 is listed as the default filesystem. Even though on most PC-class hardware, some kind of data loss is likely on all filesystems if you pull the power, a link above shows that ext3 is designed to better handle some common cases here. So, if reiserfs is mentioned, I think you should note that reiserfs has had occasional problems and is slightly more endangered by power loss than other filesystems. If someone here can demonstrate that reiserfs is faster than ext3 for portage or some other use case, you should mention that. But right now this bug is mostly talk, so I don't think you should write that until we have a reference. Similarly for XFS and power loss concerns, I don't think they should be mentioned until some hard research is done.
(In reply to comment #18) > Speaking from working on kernel bugs for a long while: > > We've only had a couple of ext2/3 bugs over the last few years: > - a strange problem with huge volumes (petabyte size), fixed > - a harmless trace being printed after you mount the filesystem under windows > using the ext2 driver there (being worked on) > > We have had reiserfs bugs, resulting in data corruption/freezes/... Only > occasionally, but they have been there. There's still another factor, Daniel, which you don't mention. Going forward, my personal research (based in part on some of your writing) indicated that ReiserFS is fairly close to being an orphaned project. I believe there are only one or two people working actively on it. On the other hand, ext3 is supported by a larger and much more active developer community. Apparently there's going to be a very straightforward upgrade path to ext4, when it arrives. No such ready upgrade path is planned or under development for ReiserFS, to the best of my knowledge. Even if ReiserFS is faster the ext3 for some purposes now, and in many circumstances just as reliable, how will it stack up 4 years from now - well within the lifetime of a well-maintained Linux server with quality hard drives. > So, what I would suggest is that ext3 is listed as the default filesystem. This would be wise, IMHO. > If someone here can demonstrate that reiserfs is faster than ext3 for portage > or some other use case, you should mention that. But right now this bug is > mostly talk, so I don't think you should write that until we have a reference. After some research, shortly after my original post, I found Justin Piszcz's excellent and apparently carefully done performance comparison of ext2, ext3, jfs, xfs and reiserfs, available at http://linuxgazette.net/102/piszcz.html and http://linuxgazette.net/122/piszcz.html. I don't believe it gets much better than this.
I must agree that the handbook needs to change. I suggest modifications to the descriptions of all file systems sans ext2 to better describe the strengths and weaknesses. My proposed revisions follow. ext3 is the journaled version of the ext2 filesystem, providing metadata journaling for fast recovery in addition to other enhanced journaling modes like full data and ordered data journaling. It uses an HTree index that enables high performance in almost all situations. Ext3 is quick to mount and unmount partitions, and outperforms other choices when working with common files. Ext3 less efficient than other choices when storing data and will fit less data in the same size disk compared to other choices. ReiserFS is a B+tree-based filesystem with metadata journaling. ReiserFS uses disk space efficiently, fitting more data into the same size disk and is very quick with file searches and directory listings. Reiser is slow when working with large files, is CPU intensive, and has a history of bugs, but is now considered stable. ReiserFS is noticeably slower than all other choices when mounting and unmounting file systems. XFS is a filesystem with metadata journaling which comes with a robust feature-set and is optimized for scalability. It uses the disk space efficiently, mounts and unmounts promptly, works with large files well and is very quick deleting them with good performance working with average files. This choice is only recommended if you have an uninterruptible power supply. Because XFS aggressively caches in-transit data in RAM, improperly designed programs (those that don't take proper precautions when writing files to disk and there are quite a few of them) can lose a good deal of data if the system goes down unexpectedly. JFS is IBM's high-performance journaling filesystem and offers very low CPU usage, very fast mounting/unmounting of file systems, great speed in working with large files. JFS suffers from latency when working with files in large trees which may make it a poor choice for /usr/portage. ---------------------------------------------------------- Some notes on how I came to these conclusions follow. A good article on this: http://www.debian-administration.org/articles/388 I assume the handbook is quoting Justin Piszcz (http://linuxgazette.net/102/piszcz.html) however, it is important to note that his tests were done on empty files. Who ever deletes 10,000 empty directories in real life often enough to choose a FS based on such a benchmark? Also, there has been some discussion on the linux-kernel mailing list with various result, but probably more percise measurments. Hans Reiser of course presents benchmarks that favor Reiser, but his methods seem flawed. See these among others: http://lwn.net/Articles/21602/ I also thought it was time to remove the "it is brand new" warning from JFS as it was merged into the kenel before XFS was if that speaks to its stability in any way.
All of those benchmarks are from a long while ago and are very unlikely to be valid today.
(In reply to comment #18) > Speaking from working on kernel bugs for a long while: > > We've only had a couple of ext2/3 bugs over the last few years: > We have had reiserfs bugs, resulting in data corruption/freezes/... Only > occasionally, but they have been there. > > So, what I would suggest is that ext3 is listed as the default filesystem. > It would be good to have some info on the options you can set for ext3, as I understand some of them need to be set from creation (directory or summat) but can make a real difference to performance. A bit like having the reiser notail option mentioned in /etc/fstab, which has always been handy on install. > Even though on most PC-class hardware, some kind of data loss is likely on > all filesystems if you pull the power, a link above shows that ext3 is > designed to better handle some common cases here. So, if reiserfs is > mentioned, I think you should note that reiserfs has had occasional problems > and is slightly more endangered by power loss than other filesystems. > I think mentioning the development status might be useful too. > If someone here can demonstrate that reiserfs is faster than ext3 for portage > or some other use case, you should mention that. But right now this bug is > mostly talk, so I don't think you should write that until we have a reference. > I think one should mention that all ebuilds (and associated files) merged from the portage tree are always checked with md5sum, so data corruption is always spotted well before anything is installed. This is also useful from a security pov. It made me feel much more comfortable about installing gentoo for business purposes, and means it's perfectly safe to try out other filesystems for the portage tree (although one should in that case keep distfiles on a separate partition imo.)
What about changing the description of reiserfs to <b>ReiserFS</b> is a B+tree-based filesystem that has very good overall performance and, according to some benchmarks, outperforms both ext2 and ext3 when dealing with small files (files less than 4k). ReiserFS also scales extremely well and has metadata journaling. Sadly, ReiserFS is far less maintained and bugs can take a while to be sorted out. ?
I believe that all the descriptions need to be changed. The glowing recommendation for Reiser is only half the problem, the other half of the problem is that the other choices are not well represented. Lindsay Haisley emailed me some editorial corrections (Thank you Lindsay) to my proposed descriptions which I can polish up if we decide to make the change.
Another grammatical correction to the above, if this is to be used: Replace "far less maintained" with "maintained far less than other filesystems" "less", in this context requires an adverbial phrase.
That all sounds great to me; the explanations are much more informative and mention concerns that users should be made aware of with all filesystems. Please can we change the default partitioning recommendation to include a home partition? It really is basic and recommended in other distros (it's been a while but I am sure mandrake had a separate /home by default.) And not mentioning cfdisk is just cruel imo ;) I'd recommend cfdisk and if it doesn't like their harddisk controller (rare ime) a link to the existing fdisk stuff would be enough. I appreciate I have discussed other stuff than reiser in this bug: i just figured if docs people are looking at this area, you'll want to do it all once. Sorry if that's bad form (please tell me and I won't repeat it.)
(In reply to comment #26) This bug is for the reiserfs text, not miscellaneous handbook changes.
(In reply to comment #24) > Lindsay Haisley emailed me some editorial corrections (Thank you Lindsay) to my > proposed descriptions which I can polish up if we decide to make the change. Yeah, please do so.
(In reply to comment #27) > (In reply to comment #26) > This bug is for the reiserfs text, not miscellaneous handbook changes. > Well I tried to open another, bug 192931 to discuss the other changes only for someone to shoot them down with no actual discussion. These aren't "miscellaneous changes" they all apply to the same page. Good luck with that.
Steve, Some of the 1st tier moderators for gentoo bugzilla can be a bit extreme, and terse. The response you got was borderline appropriate. Why not re-open the bug with a discussion of why it's appropriate that this should be done. Your comments on bug at http://bugs.gentoo.org/show_bug.cgi?id=192931#c2 actually go a long way in this direction.
(In reply to comment #30) > Steve, Some of the 1st tier moderators for gentoo bugzilla can be a bit > extreme, and terse. The response you got was borderline appropriate. Why not > re-open the bug with a discussion of why it's appropriate that this should be > done. Your comments on bug at http://bugs.gentoo.org/show_bug.cgi?id=192931#c2 > actually go a long way in this direction. No, do not reopen that bug. It will remain closed. Stay on topic and keep your comments relevant to this bug only.
(In reply to comment #30) > Steve, Some of the 1st tier moderators for gentoo bugzilla can be a bit > extreme, and terse. The response you got was borderline appropriate. Why not > re-open the bug with a discussion of why it's appropriate that this should be > done. Your comments on bug at http://bugs.gentoo.org/show_bug.cgi?id=192931#c2 > actually go a long way in this direction. > Thanks for your comment, Lindsay, but I think it's a "political" (read 'ego') thing. I don't think some of the Gentoo devs are at all happy about not recommending ricerFS. Additionally one of the paludis gimps[1] has been watching all my bugs for a long time, which really adds to my enjoyment of Gentoo.. *sigh* Heh, anyhow I offered the info and followed procedure in raising another bug; if they cba even to recommend a /home partition for their users, that's their myopic lookout. [1] rbrown: sorry i thought i made it clear: I'm straight. Please stop stalking me.
(In reply to comment #32) > Thanks for your comment, Lindsay, but I think it's a "political" (read 'ego') > thing. I don't think some of the Gentoo devs are at all happy about not > recommending ricerFS. Additionally one of the paludis gimps[1] has been > watching all my bugs for a long time, which really adds to my enjoyment of > Gentoo.. *sigh* Heh, anyhow I offered the info and followed procedure in > raising another bug; if they cba even to recommend a /home partition for their > users, that's their myopic lookout. > > [1] rbrown: sorry i thought i made it clear: I'm straight. Please stop stalking > me. Stop. Enough. There's already been a waring to keep irrelevant material off this bug. We're tired of seeing spam from you. Last warning. Bugzilla is not your personal playground, nor is it a camping ground for you to snipe at developers you dislike. We value productive comments, ideas, and *fixes* here at Gentoo, not irrelevant spewing. CCing userrel to keep an eye on further developments. Thanks.
Josh, I would like to ask that you please excuse yourself from this bug and remove yourself from the CC list. As a Gentoo dev, you have badly mishandled this exchange. We deserve better. userrel, please review posts from Steve L, Dan Drake's and my responses, and from Josh Saddler. You may also wish to review bug 192931. IMHO the Gentoo user community has been ill-served here.
(In reply to comment #21) > All of those benchmarks are from a long while ago and are very unlikely to be > valid today. Daniel, It's worth noting that Hans Ivers' article at http://www.debian-administration.org/articles/388 indicates that his work pretty much duplicates these tests, with very similar results. His article was published last year - well within the purview of the 2.6.x kernel.
(In reply to comment #34) > Josh, I would like to ask that you please excuse yourself from this bug and > remove yourself from the CC list. As a Gentoo dev, you have badly mishandled > this exchange. We deserve better. > > userrel, please review posts from Steve L, Dan Drake's and my responses, and > from Josh Saddler. You may also wish to review bug 192931. IMHO the Gentoo > user community has been ill-served here. > Speaking as a member of userrel, here's my comments. The summary is this -- reiserfs is given a glowing recommendation in the Handbook. Anecdotal evidence plus persistent users pester the development community to push the issue to change it. The decision lies in the hands of the documentation team, who can at will consult the kernel developers on recommended solutions. Disagreeing with them doesn't give anyone the right to air dirty laundry -- we don't want to know about it. Please keep the discussion on topic, relevant, and non-personal, and everything will be fine. Aside from that, I think the conversation so far has been relatively calm, so just consider this a reminder. Finally, once a decision has been made, please don't aggravate the others if you disagree with their conclusions. Here at least. That's what the forums are for.
Just a friendly reminder.... Xavier, this blocker needs to get fixed today; the networkless handbooks are due before March 1. If it's not all that important, then never mind; we'll worry about it before the final release.
Done in draft and 2008.0 versions. [01 15:16:15] <CIA-3> neysx * gentoo/xml/htdocs/doc/en/handbook/ (15 files in 3 dirs): #179796 tone down ReiserFS desc, recommend ext3 and cut some cruft
