Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Red Hat Software Businesses

Why Redhat Choose ext3 For 7.2 250

mz001b writes "There is an interesting article from RH posted on LinuxToday discussing why they chose ext3 over the other available journaling filesystems (ReiserFS, xfs, jfs,...) for RH 7.2"
This discussion has been archived. No new comments can be posted.

Why Redhat Choose ext3 For 7.2

Comments Filter:
  • i would have to say they went to ext3 because its the next version up from ext2... duhh...
  • by bconway ( 63464 ) on Wednesday August 22, 2001 @10:27AM (#2204139) Homepage
    I've worked with ext2, ext3, and ReiserFS extensively, and I can say I've had vastly different results than what many people have _read and repeated_ here. Ext2 is a nice filesystem, assuming you don't have to worry about an unclean shutdown. I can't count the number of times I've lost a filesystem entirely because it was ACTUALLY doing something when the power was lost, or just 2.4's bad VM sending the machine into oblivion and the filesystem with it. Ext3 was nice when I used it once or twice, until I turned DMA on for the disk, at which point it started corrupting itself quite nicely (not a hardware issue, trust me). I would hope this is fixed by now, but I always found it to be a nice feature. ReiserFS, but comparison, has never failed me. I've used it extensively on production machines under 2.2 and 2.4, and been using knfsd since 2.4.6 was released (damn ext2 hooks in the code, completely ridiculous). Obviously, you should find what suits your needs best, but some of the flaming and outright incorrect claims I've seen recently are just ridiculous. See what works for you, not just what RedHat tells you. I remember when Linux was about choice, not about RedHat telling me that I shouldn't use a certain filesystem on my machine and not giving me the CHOICE of doing so.
    • Read the article

      Redhat has done intensive stress testing on ext3.
    • by dhamsaic ( 410174 ) on Wednesday August 22, 2001 @10:36AM (#2204176)
      Red Hat gives you the choice to use whatever file system you want. You don't *have* to use ext3 if you upgrade to Red Hat 7.2. It says so in the article, which I'm assuming you have not yet read.


      Linux still is about choice. You can choose Red Hat, or Debian, or Suse, or Mandrake, or Progeny, or whatever you want. Inside those choices, you can choose to install whatever packages you like. And you can choose whatever filesystem suits your fancy. Red Hat isn't telling you what works for you, and it isn't telling you that you shouldn't use a certain filesystem. It says that very plainly in the article. Please read them before posting drivel like this.

    • by Anonymous Coward on Wednesday August 22, 2001 @10:37AM (#2204180)
      I've done some research on the different filesystems. The machines I used were all old Dell Dimension XPS D233's, 64M memory, 2G HDD's.

      Machine 1: Redhat 7.0/ext2
      Machine 2: Debian Woody/ext3
      Machine 3: Slack 7.0/reiserfs

      Test 1:

      The machines were elevated to a distance of 5 stories to the rooftop of a local building, or approximately 70 feet off the ground. Each machine was dropped veritcally then tested to see if this damaged the filesystem.

      Machine 1: Destroyed
      Machine 2: Destroyed
      Machine 3: Almost Destroyed, but made funny noises and started to smoke during CMOS check

      Test 2:

      Unable to test due to unpredicted destruction in test 1.

      Conclusion:

      No current filesystem for mainstream Linux systems is capable of surviving a 5-story vertical drop. Until this feature is implemented in an open source file system, it will be hard for that FS to be widely accepted.
    • I remember when Linux was about choice, not about RedHat telling me that I shouldn't use a certain filesystem on my machine and not giving me the CHOICE of doing so.

      And how are they taking away your ability to choose which filesystem to use? Did RedHat drop support for Reiser from the kernel they distribute?

      As for why they chose to use ext3, I believe they were leary about relying on a single persons knowledge of the filesystem code. Also reiser and nfs weren't playing nice the last time I looked (granted, this was a while ago).
      • Furthermore, the popular alternative being pushed by rabid SuSE fans still doesn't have a working fsck. ("It's being worked on," says Hans invariably when asked about it.) It's amazing how anti-RedHat sentiment blinds people to obvious flaws in their own preferred technology.

        If I were RedHat, I'd have done the same thing. If reiserfs screws up or is corrupted by a hardware problem, that's the end of the game -- time to mkreiserfs and restore from backup.
      • Actualy it is a shame that Redhat 7.2's installer won't allow you to select ReiserFS during install. One might argue that 'takes away choice'.

        One might also argue its not 'officialy redhat supported' and they dont care to either ;-)

        However if you look at the projects mentioned in the linuxtoday forums, it supplies modified redhat install disks which allow for ReiserFS to be chosen on install.

        I gues the main reasons why rh 7.2 chooses ext3 over reiserfs are
        - ReiserFS cannot be converted to, ext3 can
        - ReiserFS did have issues with NFS, dump, etc. (Most are fixed if not all right?)
        - RedHat should support upgrades and ReiserFS would make that impossible as ext2 could not be upgraded to ReiserFS.
    • Actualy my recent experiances with ext3 are prety decent... using it with great success on my scsi softraid volumes.

      However, i do agree, not 100% well tested software can be dangerous, not 100% tested file systems can be lethal.

      Reminds me when IBM's JFS 1.0 kernel patch came out. I spend a day converting my workstation to it, and on the first fsck.jfs that was run, my file system was -nuked-, destroyed, whiped away.. Ever since i'm waiting for the 1.1.0 release :P

      ReiserFS has seen a lot of testing over a long period of time, and has some nice b-tree's and all build in that give it better performance then ext2 in some cases.

      So use ext3 in a production envirioment? not for me anyways.. however i do plan to test it out on more experimental computers. I mean, if no one would test it, how is it supposed to become stable :)

    • I'm impressed that you were able to write that long paragraph in the three minutes since the article was posted, let alone read the message linked-to. But, I think that in your hurry, you missed a few key things, so I thought I'd quote them here for your benefit and the benefit of anyone else in too much of a rush:

      I wrote up a short piece that I hope to flesh out a bit more later on why Red Hat chose to include ext3 in this release, why you want to use it, and what we did to make it robust.
      It's not an anti-any-other-filesystem tirade at all. Don't take any part of it as meant to put down any other filesystem, even ones we have not chosen to ship yet. No hidden agenda involving alien abductions... :-)

      Red Hat is just telling you what they think works -- not taking away any of your choices. They even ship the reiserfs tools. Perhaps you've fallen to the whole "Red Hat is too popular to be cool" thing?

    • From the article, it sounds to me like RH has been doing quite a lot of research. Before 7.1 came out, they announced that they would not go with ReiserFS because of data corruption problems. They employ ext3 developers, and from the sound of the article, they have been doing quite a bit of research on stability.

      RH makes its name on being a trusted linux distribution that can be run on servers. They certainly need all this testing for business to start adopting ext3. Of course if you don't like ext3, stick with ext2, don't check any of the upgrade boxes when you are installing.

    • ReiserFS, but comparison, has never failed me. I've used it extensively on production machines under 2.2 and 2.4, and been using knfsd since 2.4.6 was released.

      Well, we had many problems here with ReiserFS/RAID0 and NFS, even after all the NFS and RAID problems were "fixed". Then we went back to ext2. Which works.

      We're thinking about maybe going to ext3 (and not because Redhat told use to do so - we're using Mandrake, and maybe going to Debian sometime). But rather, because if something goes wrong we can do a simple fall back to ext2 and we're working again.

      So, yeah, try what you think will work, be it ext2, ext3, XFS, JFS, ReiserFS, or FAT16; if it doesn't work, try something else. :)
    • I have experienced some interesteing problems with RaiserFS on SuSE 7.0. THe more interesting scenario is something like this:


      $ ls

      .

      ..

      script


      $ chmod 700 script

      $ ./script

      File Not Found


      Yet, ls still finds the file... This is a phantom problem I have only seen on RaiserFS and appears to be some sort of metadata corruption. It is really irritating because you have to create another file. To the credit of RaiserFS, the problem has not occurred since I upgraded to SuSE 7.1.

  • Well, all I have to say is.... I've used reiserFS for quite a while now.... and I've had some interruptions in power.... causing an unweildly shutdown or two..... and I do have to say that you *can* end up with errors all the same.... so don't trust ext3fs to save your butt....... instead invest in a good backup util *and* get yourself a UPS.

    Better safe than sorry they say... it is true.
    • The same could be said for ext2, really... but the idea is that after an "unclean" shutdown you don't have to wait as long for a disk check... at least that's what I look to either reiserFS or EXT3 for... When you start looking at really large disk arrays - ext2 fsck takes a helluva long time.

      Yes, backups and a UPS are alway necesary for mission critical stuff... but this adds another layer of 'help'.
    • I'm anything but a filesystem expert, but from what I know, a journaling filesystem doesn't magically protect your files against damage. If power fails while writing to your disk, even journaling filesystems won't be able to complete the write later, the data simply isn't stored anywhere.

      What the journaling system can do is have a very short disk check time during reboot, because it doesn't have to scan the complete disk after a crash.

    • A filesystem like reiser/ext3/xfs is only designed to guarantee the internal consistency of the filesystem and metadata after a power failure. No guarantees are made about the data itself.

      Contrary to popular misunderstanding, using a journaled filesystem does not mean you can start using the power switch before doing a proper shutdown -- try this and you will lose data on any filesystem. It's just that on the journaled filesystems, the risk of further filesystem corruption as a result of power failure is drastically reduced and there is no long delay to analyze the entire filesystem for consistency when powering up again.
  • Since Slash 2.2 supports journals [slashdot.org] I don't see why they didn't use that instead!

    euh ... ok wait ...

    bad bad taste :)
  • by n3m6 ( 101260 ) <<abdulla.faraz> <at> <gmail.com>> on Wednesday August 22, 2001 @10:37AM (#2204182) Homepage Journal
    why did they choose to use ext3 ?

    ofcourse its the migration path. Users can choose to install ext3 and later if they want to they can choose to go back to ext2. forward and backwards compatiblity makes ext3 a much more friendly jouraling filesystem for businesses. Some of the intranet servers cannot risk to backup and hope the new filesystem to go up working alright. Ofcourse there are better journaling filesystems out there. But the choice to use ext3 is good one since, its mature,stable and easier to administrate and use. Easier to administrate and use the keywords here. Any kernel out there can read an ext3 partition without extra modules. So it definitely plays well with others. Is there any other journaling filesystem that can say this ?

    • Migration is indeed very important.

      I once tried creating a boot disk which supports ReiserFS in order to fix a broken linux machine, and couldn't find anything like that ANYWHERE. I didn't have any linux machine near me, so I couldn't create one myself...

      At least ext3 will not have that problem.
      • Re:Migration goot (Score:3, Informative)

        by Chaostrophy ( 925 )
        http://cambuca.ldhs.cetuc.puc-rio.br/ has a install disk for RH & ReiserFS, I expect you could
        use it for recovery.

        These make nice emergency disks, including ssh:
        http://www.lnx-bbc.org/ The LNX-BBC is a mini Linux-distribution, small enough to fit on a CD-ROM that has been cut, pressed, or molded to the size and shape of a business card.

    • Of course, "better journaling filesystem" isn't as simple as who uses trees and tails and whatnot. Maturity of tools is more practical than buzzword compliance, and at this point reiserfsck can't touch e2fsck. This is probably as big as reason as any for RedHat going ext3 over reiserfs.
      That, and the fact that ext3 is more stable now than reiserfs was when SuSE shipped it to its guinea p^W^Wusers ... this is why I no longer use that particular distro.

    • Except for those of us who already have ReiserFS on all our partitions. But that's OK. Even though ReiserFS has worked perfectly for me (no problems at all, even with power failures and everything) I'm willing to give ext3 a chance. I'll probably have one of my partitions reformatted to ext3 and and see how each of them performs. And when I have the winner, I'll convert the machines at work (which are still running on good ole' ext2) to it. IMO, the more choices you have, the better.
    • > But the choice to use ext3 is good one since, its mature,stable and easier to administrate and use.

      I would contest that it's mature (it is brand new), and time will tell if it's stable. Personally I tend to think that filesystems take longer to shake out than the operating systems that use them. The fact that it's largely additive to ext2 and fixes its biggest wart (metadata integrity) makes it quite appealing.

      Now if we could see softupdates applied to the ext2 side, I'd be willing to switch servers from BSD over to it (I understand reiser is faster than softupdates, but it needs a lot more time in the oven, being such a radical redesign). Well, to debian with source .debs anyway, not redhat and rpm versioning hell.
      • it's fairly mature as it is not a whole new filesystem, but rather took ext2 and branched to start building ext2 with journaling. This way, ext3 builds on ext2's strengths.

        http://olstrans.sourceforge.net/release/OLS2000-ex t3/OLS2000-ext3.html [sourceforge.net] is a good place to go and read about ext3 from a speach Dr Stephen Tweedie made to the 2000 Ottawa Linux Symposium.

      • I would contest that it's mature (it is brand new)

        But, you see, it isn't. Not really. The journaling part is new, but in most other respects this filesystem is many years old. Unlike Reiser which has a brand new never before used filesystem layout. ext3's filesystem layout is so old, an old bo (Debian 1.3) system could read it. So I would contest that it's "brand new". In many ways, it's the one of the most mature filesystems available at the moment...

    • I think so too. The main reason I'm still using ext2 is because of the hassle in converting to Reiser. Plus I've heard about data corruption, and the tools suck! With ext3 RH will upgrade if you want it to, and it uses the more mature ext2 tools. I still wouldn't trust it too far on reliability, but that's what backups are for.
  • I mean... I was really pully for NTFS, I wasn't expecting ext3 to even be in the running...

  • It may not be an objective research but RefiserFS homepage (namesys.com [namesys.com]) claims that reiser defeats ext2 on performance.


    I assume that since ext3 only adds journaling to ext2, reiser is "faster" than ext3 also.


    Again this is the claim of reiser people.

    • Re:Performance... (Score:3, Informative)

      by Erik Hensema ( 12898 )

      Reiser performs better than ext2 mainly on two points:

      • Large directory handling
      • Space allocation

      ext2 uses a linear search algorithm to index directories while Reiser uses a hashtable. This makes handing of large (10000+ files) directories far more efficient. No more need for /home/h/he/hensema.

      Reiserfs also packs together the 'tails' of files, meaning that multiple endings of files can occupy the same disk block. This saves space (less slack). The classic example where this works very well is a newsspool, containing hunderds of thousands of files sized typically around 4 KB.

      I'm not sure wether the special Reiserfs API has been implemented which can allocate files without names but using their hash-index. This may speed up processes like squid, which have to store vast amount of files but don't care about their names. Cutting out the directory layer completely is a very nice sollution.


      • Currently squid is slower on ReiserFS compared to ext2 because squid is optimized for ext2.

        And if you put the squid files on a seperate partition you don't need journaling anyway if you automatically reformat the partition after a crash.
  • Let's see...
    RedHat came up with ext3. Alan Cox works for RedHat. AC has already made patches to the kernel for ext3.
    Hmmm... the math isn't tough for this one.

    (Granted I haven't read the article, it seems to be /.'ed, but...)
    • You are missing a little from your math. Alan Cox is not relevant in this case.

      Stephen Tweedie is. He is one of the top filesystem ext[23] hackers and is employed by Redhat. RedHat runs the mailing list for ext2 and ext3 stuff.

      But mostly, ext3 allows new filesystems to be employed over old existing ones without a backup and re-creation of the file system. This means ext3 will be deployed (in the US) 10 times more than any other journaled file system.

      As for speed, I think the ext[23] file systems, which are already fast, are going to catch up with the addition of an inode hash from Daniel Phillips. Or with his Tux2 file system which is in development. But really, unless you use directories with a large number of small files, ext2 and ReiserFS are not much different for speed.

      Having an EASY upgrade path is the way. I also suspect Linus will add ext3 to the mainline kernels in another 2-3 kernel iterations, since the ext3 hackers are quite used to the appropriate methods for getting new code included.
      • Yes, I admit I skipped over some of the technicalities, but my point still remains. Alan has already written the kernel patch. He works for RedHat. They NEED (have you checked their stock recently?) a return on their envestment.

        I personally use Reiser. I feel (and so the BenchMarks) that it is superiour to (most) of anything else out there.
        Disclaimer:
        I haven't used ext3. I'm going on benchmarks and my personal eperience alone on that.
        • Yes, I admit I skipped over some of the technicalities, but my point still remains. Alan has already written the kernel patch. He works for RedHat.

          Stephen Tweedie and Ted T'so wrote ext3, mostly. Andrew Morton led its port to the 2.4 filesystem, and maintains patches for ext3 to be applied to the 2.4 kernels.

          Alan Cox merges those submitted patches into his ac series, which ultimately leads to Linus adding them to the "stock" kernels.
  • I would love to read that article, but, since LinuxToday uses fixed-size tables, I quickly grew tired of left-right scrolling just to get to read a single line of text.

    Even if I resize the window, the whole page doesn't fit on my screen.

    Who the hell let the monkey design the website?

    - A.P.
  • by hal0802 ( 240758 ) on Wednesday August 22, 2001 @10:55AM (#2204253)
    ... since Alan Cox (@redhat.com) had so many arguments over the Linux kernel Mailing List with Hans Reiser.
    This thread [indiana.edu] is a good example.
    • I kinda think that this [indiana.edu] is a far better link.
    • After having read the posts in that thread, it sounds like RedHat did extensive testing of ReiserFS and found several bugs (many of which have since been fixed).

      Not sure why you make out the arguments to be overly personal. Alan seemed quite willing to accept reiserfs patches in the AC kernels.

    • When Redhat 7.1 was released, someone here on slashdot wondered why reiser was not part of the distro. A redhat employee posted that under certian conditions with heavy file i/o tests, the filesystem became corrupted. I am sure the bug is not very common but on a corporate server it should not be installed. The article has been slashdotted so I have no idea what it said about rieser or the other filesystems but I assume that the other filesystems were not fully tested enough with the linux kernel so were not included.

      Also remember that redhat is made and used for bussiness oriented servers and workstations where stability and reliability over cutting edge technology is very important. I would not want to bet my job on a new technology until its very matured. Redhat needs to take it slow due to their market. You can always use a more bleeding edge distro like mandrake. Also reiser is available on the Redhat Powertools cd with the deluxe or server edition of RH 7.1 if you just have to have it.

      PS: Could someone posting anonymously post the story so I could read it. Thanks

      • Ok, I just don't buy the "it was not tested, so they did not include it". I code mostly Java these days, and I'll be damned if they have not horked up most of the RH 6.9+ releases - I even had to make a symb link to cut in 7.1 (I think, been a while now). GCC was a bit of a mess to for the C++ work, and Oracle continues to be its own special place in install hell.. Anyhow, as a workstation class OS, you would think things like that would catch someone's eye rather than some obscure FID like error.... smells like politics to me...

        As for betting your job on new technology, cutting edge still pays better than the stable stuff - kidding here, I know what you are trying to say - if the cutting edge is not greased with the blood of developers, its the ops folks who are next in line for the sacrifice... A bit more QA might be in order between final cuts. Guess I should grab those 7.2b ISO's and get testing again. {Grin}

  • by Zenithal ( 115213 ) on Wednesday August 22, 2001 @10:57AM (#2204260) Homepage
    I've been interested in upgrading the FS on the machines I manage here in the office, give or take about 15 servers. The fact of the matter is that it is no small job bringing down a production machine to change its filesystem. So, it sits with an unjournaled ext2 fs. Which is where it would sit, potentially forever until it left the production scope. The ability to upgrade the FS to ext3 without even a reboot, AND maintaining the security of being able to roll back those changes are more than enough to convince me that this is the best way to go.

    If I push to have the systems upgraded, say to ReiserFS, and something goes wrong. I'm just plain f**ked. It's that simple. This offers me the ability to upgrade with a fraction of the risk. Which, considering RedHats duties to its customers, I think is the perfect decision.
  • My first thought was that it's because Stephen Tweedie, lead developer of ext3, works for RedHat. ReiserFS was developed primarily by SUSE. JFS and XFS come from IBM and SGI.

    So I read the article, and all of those reasons could easily apply to any of the above filesystems. Never mind that all of them are more mature and more stable than ext3. The only technical argument for ext3 is the upgrade path: ext3 is ext2 with a journal. But the real reason might be that RH can speed adoption (and by the bazaar model, improvement) of ext3, developed at RedHat, this way.

    • My first thought was that it's because Stephen Tweedie, lead developer of ext3, works for RedHat. ReiserFS was developed primarily by SUSE. JFS and XFS come from IBM and SGI. / So I read the article, and all of those reasons could easily apply to any of the above filesystems.

      Your very thorough reading probably missed this surprising section:

      "Easy transition:
      It is easy to change from ext2 to ext3 and gain the benefits of a robust journaling file system, without reformatting. That's right, no need to do a long, tedious, and error-prone backup, reformat, restore operation in order to experience the advantages of ext3."

      It could happen to anyone. I know I had to read the article half-way before I even saw it!

  • After an unclean system shutdown (unexpected power failure, system crash)...

    Power failures have been known to occur sometimes, but I've never had Linux crash.

  • Not what it says! (Score:5, Informative)

    by arestivo ( 459117 ) on Wednesday August 22, 2001 @11:14AM (#2204337)
    I wonder if who posted this article even read the original one.

    The article at LinuxToday isn't about RedHat prefering ext3 over other journaling filesystems. It's merely an explaination of why they decided to include ext3 in the new RedHat 7.2.

    ... I wrote up a short piece that I hope to flesh out a bit more later on why Red Hat chose to include ext3 in this release ...

    The only comparison made is between ext3 and ext2 where they explain the advantages of a journaling system.

  • This site seems to be slashdotted.

    The guy from Atheos (http://www.atheos.cx/) calls Slashdotting " The worst mass attack I have ever seen". Because this seems to be a continual (and somewhat legendary) problem, I think the powers that be (Taco et al) should put a system in place wherein they give sysadmins some sort of warning before they post a slashdot article which could take down their website with a "Friendly DDOS".

    As Spiderman says, "With great power comes great responsibility", and Slashdot's power to strain system resources is very great, indeed.
  • by DaveWood ( 101146 ) on Wednesday August 22, 2001 @11:17AM (#2204358) Homepage
    As our partition continued to grow, from 13GB to 37GB to 50GB and now 100 and soon to grow again (and there are hundreds of thousands of files), somewhere around the 50GB mark ext2 started to get a little overburdened.


    Linux has never crashed on me without a hardware problem causing it (not an exaggeration), but that doesn't mean we haven't had plenty of hardware problems, and each time there was a failure, the fsck would take 30-45 minutes. My first thought was ext3, but... heh. It was always grayed out in the kernel config menus. Not a good sign. ReiserFS on the other hand was immediately available.


    Of course, you don't trust your data to something without being damn thorough about it, so I did a bunch of tests on staging servers (which went great) and I spent a lot of time reading Hans Reiser, who impressed me considerably as a smart person with a lot of good ideas. We made the move this spring and have had zero problems with the filesystem during normal operations. Zero. It's blazing fast on our tests, it appears to scale beautifully, and if I go down, I have no wait time anymore coming back up.


    Of course, I keep up with the kernel changes and upgrade when I see updates relevant to the filesystem.


    It's not a perfect package, but nearly. Its consistency checker/repair tool (reiserfsck) is not finished (as its messages vigorously warn). Now, remember, this is not the same thing as e2fsck. You are not using it in the same role, its purpose is much more specialized (disaster recovery), so the significance is different. Still; we came to use it during several of the many times high-speed SCSI chomped on our asses and corrupted data. We have backups, of course, but I wanted to see what the tool was capable of. In several cases it was able to successfully rebuild the filesystem, very slowly, with --rebuilddb, but in several other cases, the tool would dump core, which, if you were one of those fools without a backup, would leave you stranded.


    Even in this, however, I was reassured; the maintainer of the tool answers emails quickly and was eager to try to troubleshoot the problem. I thus have no doubt that it will quickly mature into something quite good. It's just not there at this moment.


    On the whole I would say I'm extremely happy with ReiserFS; we've punished it here pretty brutally and it's passed every test. I don't have any experience with ext3, but anecdotally I'm told it's less mature. Still, I have nothing against it. I can only comment that I hope Redhat's upgrade process from 7.1 to 7.2 will at least take reiserfs into account, instead of breaking the way it did from 7.0 to 7.1.

    • Both at home, and at work, running various versions of the 2.2 kernel plus patches, stock Mandrake installs, 2.4 kernel, etc. we have, over time, experienced data loss using reiserfs. This has not been limited to one machine, or one configuration, or one version of the filesystem (though, admittedly, we have been unwilling to try any newer versions in the last six months or so ... let someone else take the pain for a while).

      I say this not to knock reiser per se (I am quite happy it made it into the kernel tree, although I won't be completely happy until ext3, jfs, and xfs are all in the kernel tree as well so that they can compete with one another on quality and features rather than merely convinience), but to point out that all is not necessarilly sunny, nor is it unequivocably the "leader" when it comes to Linux journalling filesystems. I feel it is important to counterbalance some of these overly sunny depictions of experimental filesystems being used in serious environments with a little real-world, personal experience to the contrary.

      I haven't yet tried ext3 or jfs, but have used various incarnations of xfs and must say that I have developed a preference for it over the last few weeks. That having been said, I still make use of ext2 filesystems in production environments and will only use less tried linux filesystems (previously reiser, now ext3 and xfs) in development/test environments only ... at least for the nonce. I concur with another poster who pointed out that SGI's XFS has been well tested and stable since 1994 ... any issues are porting issues, not design or internal issues, which IMHO is quite important when looking for a managable and stable alternative.

      These filesystems are fun and exciting, but they are not perfect, and in the case of reiser some rather serious (hopefully now fixed, but what's next?) flaws have gotten played down a little more than they should have. Remember, back up early, back up often, and be conservative in using any of them in anything other than a test situation (you can, once its tested to your satisfaction, but be cautious).

      Back up early and back up often.
    • I can only comment that I hope Redhat's upgrade process from 7.1 to 7.2 will at least take reiserfs into account, instead of breaking the way it did from 7.0 to 7.1.

      It doesn't.
      It'll recognize and keep your partitions.
      • Well, since 7.2 is an early beta, perhaps that should be "not yet". At least one can hope. I note that Linux Today (I think) today had a story about someone who what issuing a Reisser based Red Hat 7.2 distribution, with the comment that they would start shipping as soon as 7.2 was final. Didn't follow it up, but it was there.
    • I have experienced some extremely severe system file metadata corruption under ReiserFS. The example was posted previously but basically, the problem involves an inability for the system to find the file when it is trying to execute it, even though the file can still be read and modified in an editor (yes, permission is granted, and the error specifically indicates a file not found type of error).


      The only resolution I could come up with was to recreate a new file. It was limited to our ReiserFS / partition, and was most common with the rc.d scripts. This was a major headache and I decided that the journal did give some advantages but at that time (SuSE 7.0) was not ready for prime time, as it added additional ways things could go wrong.


      This problem had a habit of preventing certain important services from starting because the metadata for the startup scripts would become corrupt. It was an issue for us, and it has not made us very favorable towards ReiserFS. In fact it prevented further migration.

  • XFS anyone? (Score:5, Insightful)

    by greenfly ( 40953 ) on Wednesday August 22, 2001 @11:17AM (#2204361)
    I'm suprised that more people haven't said anything about XFS. I've been using for awhile now at home and on a production fileserver at work for awhile now and haven't experienced any problems. The only thing at all that has been a worry is the fact that Grub can not yet read XFS, so you have to create a small boot drive at the beginning. At least with XFS, the filesystem has already been designed and tested for years by SGI, and the only matter was porting it to Linux. From what I've seen with ReiserFS, they are still trying to decide on features and on how it is going to go about doing things. That's fine and all, but I don't want to end up having to backup and restore my filesystem a few times as they decide to impliment a new "everything and the kitchen sink" feature. If I'm doing something for file integrity and security, I'd rather have something that I know has been working for years now in a high performance environment. Just so this won't be considered offtopic, I would say that I can see why ext3 would be preferred by Redhat over Reiser (with the in-house development, and the easier migration), and hey, it will probably be "good enough" for most people (and certainly some kind of journaling is better than plain ext2), so hey, good for Redhat, and good for their users. I'll continue using XFS, but that's what's nice about choice anyway, right?
    • The only thing at all that has been a worry is the fact that Grub can not yet read XFS

      I didn't know that. I have XFS running on all partitions including root on five machines (4 debian, 1 mandrake).

      I've had no problems, either. XFS is awesome!

      I wish Linus would put it into 2.5, and I wish Alan would then backport it to 2.4. I think it's proven itself.

    • Forgot to mention explicitly in my last post. I use LILO with my XFS-root-partition machines.

      BTW, people can get more information about XFS, or download patches or kernel source from the SGI Linux XFS [sgi.com] site. CVS is also available.

  • I wonder which type of fs linuxtoday has,
    because it seems to be in a little /. trouble.
  • 1 reason and 1 reason only they didn't go with reiser. NIH. Not Invented Here. Pridefull tech companies like Intel are notorious for this. Too bad for all involved.
  • Easier Partitioning (Score:4, Interesting)

    by GroundBounce ( 20126 ) on Wednesday August 22, 2001 @11:22AM (#2204390)
    I use Partition Magic on a regular basis to manage my partitions, resizing and moving them around as needed. (I know, it's commercial software, but it's one of the more useful pieces of commercial software out there, especially if you like to change things around a lot on your systems.)

    PM supports ext2 but not any of the newer exotic journaling file systems like ReiserFS or xfs.

    The fact that ext3 is comatable with ext2, and can be converted back and forth is a welcome feature for those who use PM to manage their partitions.
    • It's just as easy to resize with GPL'ed tools. I've had times where Partition Magic is not avaliable to me, and I needed to resize a partition. I loaded up a boot disk with a copy of resize2fs and away it went.

      resize_reiserfs works much in the same way.

      I'm honestly not sure if the metadata and journal will be fully compatable with Partition Magic. It may just lead to a corrupt partition, but hell, that's what backups are for.
      • I'm honestly not sure if the metadata and journal will be fully compatable with Partition Magic.

        I'm not sure either. My plan is to try it on a fresh install once I upgrade to RH7.2 and see if it works. If it corrupts everything, no biggie since it was a fresh install.

        It may also be that PM might refuse to recognize it if the partition type ID is different for ext3 (which I assume it is, although I don't know for sure).

        The nice thing about ext3 in either of these cases is that you can back-convert to ext2, resize the partition, and re-convert to ext3.

        BTW, I agree with your comments on alternative partitioning tools; but I have been a PM user for many years and have come to trust it, so I haven't felt like changing even though good GPL'd tools are now available.
        • "I haven't felt like changing even though good GPL'd tools are now available."

          I've used Partition Magic for a few years too, and I haven't see any Free alternatives around, apart from fips, and, well that comes no-where near PM for features.

          Do you have the names of any of the 'new' ones?

  • i dual boot
    if i want to read linux files from windows i have only one tool at my disposal and its called explore2fs. this tool is very useful to me and would not choose lightly to change my linux filesystem.
    for standalone linux machines this is not even an issue.
    (dont suggest VMware i dont want to pay for it so i simply wont use it)
  • There's an interesting review of different file systems here [linuxgazette.com]
  • and they want to define what Linux is. That's not so hard to understand.

    Yes, I'm a Linux user, yes, I have it pre-loaded onto computers I buy for work and will sing it's virtues all day long, but RedHat is still a company and does have to make money. If they've tested the filesystems and one type works better for what Redhat needs in a filesystem, it doesn't take a brain surgeon to figure out which filesystem they're going to use.

    The good news is that you can have a dozen filesystems on your hard drive and mount each and every one of them and not have to worry about which one is what when it comes time to go to that directory.

    DanH
    • More importantly RedHat went with Ext3 because it offers similar performace, potentially greater reliability (since it is based on ext2 code) and most importantly, upgrading from ext2 to ext3 is much more straightforward.

      RedHat has a lot of existing customers. Providing them with an upgrade path to a journaled is a clear win for them. ReiseFS may have been first, and it almost certainly is better in some situations (and not particularly worse in others). However, it requires a much more painful transition, it isn't backwards compatible with ext2, and it doesn't come with the wide array of bulletproof recovery tools that ext3 inherits from ext2.

      The beautty of Linux is (as you pointed out) we Linux users get to pick and choose from a growing assortment of very acceptable choices. We are literally being drowned with cool filesystems, and once they are mounted they will all act similarly to the 'ls -la' command.

      Linux rocks!

  • Here's my reasoning:

    * Any non-trivial choice in the computer world has its pros and cons.

    * Magically, Michael Johnson only finds pros in adopting ext3.

    Conclusion: Michael Johnson is not fully confronting the issue or being fully objective and upfront.

    • Actually, the article is the reasons why we're using ext3 as the default filesystem. It is not as a full comparison between ext3 and the other options.

      Yes, other filesystems have some advantages under some circumstances. Nobody here would contradict to that statement.
      ext3 simply happens to be the only filesystem that has all the pros listed in the article, and those are the most important ones IOO.
  • ext2 - hmmm, too cold.

    ReiserFS - mmmm... too hot.

    ext3 - mmmmm.... Ah! Just right!

  • ReiserFS? Ext3? XFS? JFS?


    =WHY CARE WHICH???=


    Once you've formatted the partition, and loaded the appropriate FS driver, you don't =NEED= to care what the underlying filesystem is. There is NO DIFFERENCE!


    From the perspective of Red Hat, or any other distribution, the difference in effort of supporting one journalling FS or a hundred is negligable. A menu is a menu is a menu. The number of items on it is irrelevent.


    From the perspective of the user, it doesn't make a difference, either. Oh, it's a pull-down menu! Wow! Never seen one of those before, I wonder how it works. Duh! Give even novice users the wits to ignore things they don't understand, and expert users the freedom to tweak things they DO understand. Futher, since ALL filing systems behave in much the same way, from the user's standpoint, it doesn't make a damn bit of difference whether someone "messes up" on this or not.

  • I did not see any mention on the article on whether other journaling file systems would be available on Red Hat 7.2 as part of the installation/upgrade procedure.

    I am have been using ReiserFS for about 18 months now and greatly appreciate it on my 20 gig hard drive on my laptop. Never had a single corruption problem, and always rebooting the machine quickly (specially with VMware crashing the system ;-)

    Some systems at Ximian use XFS extensively as well. When you have too many files in a directory (for example Gnus spools) ext2/ext2 wont cut it due to the slow operations on directories with lots of files.

    Miguel.
  • Hmm this will be interesting. My machine has had a few unexpected shutdowns, and I have had to run fsck on them. With a 30 GIg drive it actually was faster than with my old system. Of course it helps that I have a super fast computer these days (1.2Gighz with WD 7200RPM drive). I'd imagine that soon I can have my dream of instant on / instant off machine ;-).
    • That's all well and good, but when one of our RAID5 140GIG dual 700MHZ machines goes down hard for some reason (which has happened a couple times), it is nice not to have to wait 20 minutes for the machine that has 2-6 hits a second check it's hard drives. Every second counts.

      (We had some wierd NFS problem from an AS/400 that caused Linux to lock.) While it's not a big deal for home users. Production servers are a much different story.

      -Pete
  • by RedDirt ( 3122 ) on Wednesday August 22, 2001 @01:24PM (#2204783) Homepage
    RedHat has been VERY good about not radically changing their platform between point releases so I'm not surprised to see this incremental filesystem improvement.

    I would, however, be surprised to see them skip XFS, JFS or ReiserFS in their 8.0 release. It would make sense for them to add that capability at that time (and would allow the implementations to mature that much more).

    -- James
  • by ajs ( 35943 )
    Allusion is made in the article to the future use of NVRAM for the journal. Now, I know how much a performance win this would be, but doesn't NetApp hold a patent on that?

    Can someone with more patent-searching skills than myself verify? Thanks!
  • So, where is it? (Score:3, Interesting)

    by Pflipp ( 130638 ) on Wednesday August 22, 2001 @01:59PM (#2204906)
    (Sorry if I be a little short-sentenced. I just wrote a whole story then Mozilla went nuts so now I am doing it again.)

    Two things: First, with 2.4 we were `promised' journaling and devfs. Both are still marked experimental, and of journaling, only ReiserFS is included as an appetizer, but the subsystem is still heavily in development. Some smaller things that were supposed to be improved at 2.4 are also still marked experimental. My guess is that most people -like me- are still using ext2 and device nodes, silently but eagerly waiting until journaling and devfs (and these other smaller things) get marked `stable' (by the proper authorities ;-), and that, as a result, journaling and devfs will really become mainstream when 2.5 is in good sight. So while 2.4 was supposed to bring us these two big features, in reality, well, it doesn't. Yes, I know, it provides the basis, is being worked on, can be obtained by patches etc. etc., but that doesn't practically make it much difference from 2.2, because as I said, for what I guess, most people still aren't encouraged to take the step to a journaling filesystem.

    Second: think GCC-2.96 (IIRC). RedHat has the power to shape the Free Software market a little bit the way they like it. With the inclusion of the compiler marked as GCC-2.96 they have practically released a GCC version without involving the GCC team. When RedHat issues a kernel that does ext3 (not just as an option, but as a default feature), I guess at least some of the results are the same as with the GCC-2.96 case. Although maybe this time not `faced with the facts' (that RedHat issued GCC-2.96), but merely `by popular demand' (from other distro's that want to use journaling by now), there will be some pressure on other distro's and the kernel developers to get journalining in.

    Hmm. Maybe I'm really exaggerating the case. And do keep in mind that I'm not mad that I don't `get what I'm promised' or something like that. It just makes me nervous that I can't find ext3 anywhere in my fresh kernel sources (2.4.7; debian testing doesn't have 2.4.8 yet but I don't think the differences are that big wrt journaling and `marked experimental' stuff AFAIK from the changelogs) while the ext3 patches for the 2.2 series _are_ in the distro. And I really can use that stable VM of 2.4; earlier on the GIMP crashed my box, now it just crashes itself when loading huge things. I do get complete keyboard blocks once in a while, but no trashing anymore, and hey, that's what the reset button was built for, right?

    Which brings us back to journaling.... Oh well ;-)
  • Not 100% on topic, but somewhat related: The second beta has been released yesterday. You can get it at ftp://ftp.redhat.com/pub/redhat/linux/beta/roswell / [redhat.com].
  • Is there still a two gig max file size limitation? I'm assuming so, since this seems to mainly be ext2fs with journaling tacked onto it.

Business is a good game -- lots of competition and minimum of rules. You keep score with money. -- Nolan Bushnell, founder of Atari

Working...