Slashdot Mirror

← Back to Stories (view on slashdot.org)

ext3fs in Linus' Kernel Tree

Posted by michael on from the journaling-for-the-unshaven-masses dept.

peloy writes: "According to Linus' changelog for Linux 2.4.15pre2, the long waited ext3fs, the sucessor of ext2 with jounaling capabilities, has finally made its way into the official kernel tree. I have never tried ext3fs but it looks that now that it is "blessed" by Linus I'll be upgrading my old and trusty ext2fs partitions soon."

105 of 384 comments (clear)

  1. In the immortal words of Monty Python... by los+furtive · · Score: 2, Redundant

    ...and there was much rejoicing.

    --

    I'm a writer, a poet, a genius, I know it. I don't buy software, I grow it.

  2. Hurray! by __david__ · · Score: 2, Interesting
    I've been running with the ext3 patch for a couple months now and I really like it. There's nothing like locking up your system while testing some crazy hardware, and booting back up with no fsck... I'm glad its finally "blessed"!

    Yay!

    -David

    --
    There. Now go play some cool javascript games!
  3. Finally! by alien88 · · Score: 3, Informative

    I've been running ext3 for about a month now, and it is so much better than ext2. I'm glad to see that Linus decided to merge it in. I know that there were some issues for a while with ext3 not working with the new VM, but they finally started releasing patches for the latest 2.4 kernels.

    -Alien88

  4. ext3, a journaled ext2 and not much more... by SpamapS · · Score: 5, Informative

    I've been using ext3 ever since I upgraded to 2.4.14 a few days ago. Its nice to have the journaled FS... as I have been testing out a lot of !cough!nvidia!cough! proprietary drivers and bleeding edge software lately, and subsequently crashing. W/ ext3, I can get back to the crashing very quickly.

    That said, I also use ReiserFS for some other things(try /var first, its simple to convert). It definitely speeds up the directory access... and on my squid it cut the average response time by a full half second... :-P.

    I personally think ext3 will win out, as it takes about 20 seconds to convert a 6GB partition... vs. XFS or ReiserFS taking nearly 10 minutes, and much more complexity.

    --
    SpamapS -- Undernet #Linuxhelp
    1. Re:ext3, a journaled ext2 and not much more... by psamuels · · Score: 4, Informative
      how come Office takes 20 full seconds to start up on my *4* GB system anyway?

      Because you're not really converting the filesystem. The process consists of:

      1. creating a journal file
      2. marking it as a journal file in the various copies of your superblock

      That's the beauty of ext3 - it is essentially ext2 with journaling, no more no less.

      In fact, since this is the case, you can mount an ext3 filesystem as ext2 if you ever need to - the compatibility goes both forward and backward.

      --
      "How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
    2. Re:ext3, a journaled ext2 and not much more... by Pierric · · Score: 2, Insightful

      "I did mkreiserfs on a 40gig drive and it took seconds." Yeah, creating the FS takes seconds. But if you have a filesystem you want to convert, it takes much longer and some strategy, too. Where ext3 only needs a few seconds for the creation of the journal. On my system it also require the partition to be unmounted, which is difficult for the root. But apparently, it's only on *MY* system :)

    3. Re:ext3, a journaled ext2 and not much more... by BinaryAlchemy · · Score: 2, Informative

      The problem with the nvidia drivers is that after X barfs and you kill it (CTRL+ALT+BKSP or ATL+SysRq+k) the kernel driver hangs on and doesn't let it fall back to console mode (nvidia uses a kernel driver to get direct access to the card). You can type in to the console (ATL+SysRq+s then ATL+SysRq+u then ATL+SysRq+b is my standard system when wine pukes on me), you just can't see it.

      --
      ----- The problem with browsing at +5 is that everyone thinks you're being redundant
    4. Re:ext3, a journaled ext2 and not much more... by phaze3000 · · Score: 2
      Try compiling your kernel with Magic SysRq keys and doing alt+SysRq+R next time you have a problem.

      Of course, the real solution is to use a graphics card from a vendor that doesn't treat Free Software with such contempt..

      --
      Blaming GW Bush for the Iraq war is like blaming Ronald McDonald for the poor quality of food.
    5. Re:ext3, a journaled ext2 and not much more... by gallir · · Score: 2
      Journaling file systems cannot ensure file system consistency after a crash in kernel code

      You are completely wrong. __All__ journal file systems assure __filesystem__ consistency, which means that metadada consistency is guaranteed.

      Some of them don't assure data consistency, which means the data __in__ the file could be inconsistent if there were changes not commited to disk.

      AFAIK, ext3 also provides/provided (it's expensive) data consistency.

      --
      sgis ddo ekil t'nod i
    6. Re:ext3, a journaled ext2 and not much more... by Florian+Weimer · · Score: 4, Insightful

      If the kernel crashes, it is not reasonable to assume that the journaling code worked correctly after the bug occured somewhere in the kernel. After all, random kernel memory could have been overwritten. If the kernel data structures are no longer intact, the kernel (including file system journaling) can no longer work reliably.

    7. Re:ext3, a journaled ext2 and not much more... by timster · · Score: 3, Insightful

      well if at any point, the kernel simply locks cold and doesn't do anything, the journaling will work fine since it's prepared for the case of a power outage. If the kernel gets corrupted in some odd way but doesn't write to the disk again, the journal will also be fine. You are right that filesystem integrity could be damaged by a corrupted kernel that continued to operate; it would also be possible for such a beast to install Windows XP on all its filesystems, since in that case we are by definition in an undefined condition. I think it's generally unlikely for such a thing to happen, but it's certainly possible and it's happened before (well, maybe not the Windows XP part...)

      --
      I have seen the future, and it is inconvenient.
    8. Re:ext3, a journaled ext2 and not much more... by be-fan · · Score: 2

      Dude, since when does NVIDIA treat OSS with contempt? There are two reasons why the NVIDIA driver is closed source:

      1) Intellectual property. NVIDIA doesn't own everything in the driver, and thus can't open it.

      2) Competition. ATI's OpenGL drivers suck ass (they really hold the new 8500 card back). Don't you think they'd just love to get their hands on NVIDIA's code? NVIDIA has invested a lot of time and money into making solid OpenGL drivers, why should they just let ATI have it for free? Remember, and OpenGL driver isn't like an ethernet driver. An ethernet driver just interfaces the kernel network layer to the hardware. An OpenGL ICD, on the other hand, provides the entire OpenGL subsystem, from user-level API down to banging registers on the hardware. Its like the NIC driver AND the entire kernel network stack.

      --
      A deep unwavering belief is a sure sign you're missing something...
    9. Re:ext3, a journaled ext2 and not much more... by Dwonis · · Score: 2

      We don't *want* drivers, we just want documentation. Matrox doesn't provide Linux drivers either, but they provide good documentation, and are willing to answer questions developers have. This is the reason why I'm soon going to buy a Matrox card and throw this nearly useless nVidia card into the old scrap parts bin.

    10. Re:ext3, a journaled ext2 and not much more... by be-fan · · Score: 2

      I never said ANYTHING about register specs, only OSS drivers. As a long-time BeOS user (Be couldn't pry the specs out of NVIDIA, even under NDA), I am with you in agreeing that NVIDIA should release register specs for their cards.

      --
      A deep unwavering belief is a sure sign you're missing something...
  5. Some important points... by ThatComputerGuy · · Score: 5, Informative

    Of course we'll have a lot of posts here talking about the issues of backwards compatiblity, ext3's offerings, etc, so we migh as well get those out of the way now.

    From what I understand, ext3fs is just ext2 with journaling support, so in the (somewhat rare) event of a system crash you don't have to go through a time-consuming fsck during the next boot. Results in better data protection and more uptime.

    If an ext3fs enabled kernel on an ext3 partition needs to go back to a previous kernel for some reason, or say, you forget to compile ext3 into a kernel, any ext2 kernel will still be able to read/write to an ext3 partition, as long as it was cleanly unmounted with the ext3 kernel.

    Why not push ReiserFS, XFS, etc? It seems that most of these are not very well proven yet. ext2 is tried and true, kernel support is good, and the new revision adds journaling, so why not stick with ext3?

    AFAIK, these are some of the most FAQs about ext3. I wonder how often they'll show up below...

    --
    XML is like violence. If it doesn't solve the problem, use more.
    1. Re:Some important points... by Reikk · · Score: 3, Informative

      : Why not push ReiserFS, XFS, etc? It seems that : most of these are not very well proven yet. ext2 : is tried and true, kernel support is good, and the : new revision adds journaling, so why not stick : with ext3? Bzz. Try again. XFS is extremely well proven. It's been in use for years in systems with massive storage - nuclear war simulations, automobile designing, and the area I've been dealing with the last several years, weather forecasting.

    2. Re:Some important points... by Trepidity · · Score: 2

      I believe by that comment he meant "the Linux kernel support for ext2 is well-tested and stable, while that for XFS and Reiser FS is not." It's their Linux support that's problematic, not the filesystems themselves.

      And I'm tempted to disregard any arguments that start with something as ridiculously juvenile as "Bzz. Try again."

      --
      10 PRINT CHR$(205.5+RND(1)); : GOTO 10
    3. Re:Some important points... by SurfsUp · · Score: 3, Informative

      From what I understand, ext3fs is just ext2 with journaling support,

      Yes and no. Functionally, that's strictly true. Internally, ext2 and ext3 have diverged somewhat. Ext3 does not share any common files with ext3 at this point. Ext3 is still buffer-oriented, wheras Ext2 has largely been converted to use the page cache. The page cache aspects of ext2 are expected to be added to ext3 in due course. At some point, there may be a full merge of the two code bases, though that's going to be a fair amount of work.

      --
      Life's a bitch but somebody's gotta do it.
    4. Re:Some important points... by dbarclay10 · · Score: 4, Informative

      I'd just like to clarify some of this post's points:

      From what I understand, ext3fs is just ext2 with journaling support, so in the (somewhat rare) event of a system crash you don't have to go through a time-consuming fsck during the next boot. Results in better data protection and more uptime.

      That's not entirely true for a couple of reasons; first of all, the ext3 code *started* as an exact duplicate of ext2, then they added journalling support. A lot has changed since then(in both code bases), so they're not identical any more. Secondly, journalling does not mean that there's no fsck; it just means that it's an order of magnitute or four faster. This is because during the filesystem consistency check, we know *exactly* where to look for problems(thanks to the journal). This doesn't result in better data protection, but it does result in better availability(and hence uptime).

      Why not push ReiserFS, XFS, etc? It seems that most of these are not very well proven yet. ext2 is tried and true, kernel support is good, and the new revision adds journaling, so why not stick with ext3?

      It should be noted that XFS has been around for years. I think your basic premise is still correct, though - neither XFS(in the scope of the Linux kernel) nor ReiserFS have been tested as extensively as ext3. And since ext3's code base started as ext2's code base, it doesn't even need so much checking.

      --

      Barclay family motto:
      Aut agere aut mori.
      (Either action or death.)
    5. Re:Some important points... by Anonymous Coward · · Score: 2, Funny

      >> Ext3 does not share any common files with ext3 at this point.

      So now there's a code fork, and the only difference is case sensitivity?

      Yeesh, and I thought having to distinguish between stdlib "FILE" and kernel "file" was bad.

    6. Re:Some important points... by Florian+Weimer · · Score: 2

      ext3fs is really just ext2fs with a journal. This is an advantage in some situations (backwards compatibility, for example). However, other journaling file systems (in particular XFS and ReiserFS) use more advanced data structures than ext2fs/ext3fs for storing metadata. For example, this means that performance of these filesystems is sometimes much, much better when you have got a huge number of files in a single directory.

    7. Re:Some important points... by JanneM · · Score: 4, Funny

      Almost as annoying are people that start out their reply with `No.' -- and then follow it with complete drivel.

      No. The churchmans driveyard if filled with cucumber patties. "Whallyop!" cried the toady queen, of the mice that lists the bardic salamanders.

      --
      Trust the Computer. The Computer is your friend.
    8. Re:Some important points... by Tet · · Score: 2
      For example, this means that performance of these filesystems is sometimes much, much better when you have got a huge number of files in a single directory.


      The key word there is "sometimes". Stephen Tweedie recently commented on the Linux Kernel mailing list that resierfs is significantly faster on empty filesystems, but slows down as the filesystem approaches 90% usage (which is pretty typical for a production box).

      --
      "The invisible and the non-existent look very much alike." -- Delos B. McKown
    9. Re:Some important points... by be-fan · · Score: 2, Informative

      In linux there are two caching mechanisms. The first one, called the buffer cache, caches physical disk blocks. For example, there might be a buffer that caches blocks 8-16 on a particular disk. The second one, called the page cache, is much newer and caches files. So the page cache would cache, for example, the first page of a file. The difference between the two is that the page cache is much higher level, and thus much more flexible. For example, blocks on a disk are 512 bytes in size. Pages are 4KB in size. Thus the first page of a file might be contained in 4 different blocks on different parts of the disk. The page cache doesn't have to care about that, since its up to the filesystem to map pages to blocks. The page cache also interfaces very nicely with memory mapped files. Normally what happens when a process writes to a memory mapped file is that the kernel allocates a page of memory, and allows the process to write to that page. Eventually, the kernel writes out that page of memory to the disk file. With the buffer cache, there is no connection between what the process sees (pages) and what the disk deals with (blocks). Thus, the kernel has to manually make sure that the buffer cache and the memory mappings are in sync with each other. If a process read()'s from a file that another process is writing to with memory mapping, the kernel has to make sure that any changes to the buffers (read()/write()) agree with changes in the pages (memory mapping). The page cache, on the other hand, deals only with pages. So what happens with the page cache is that when a process writes to a memory mapping, it points the process to the page that is caching that part of the file. When another process uses regular read() to read that file, the kernel simply copies that data from the caching page. Another benifet is that it lets stuff like NFS (in which the kernel never deals with a disk, just files) use the same caching mechanism as regular files. The last benifet is that you don't have to treat file caches any differently from regular memory. The Linux VM system automatically swaps out pages that haven't been touched in awhile. With the page cache, the VM doesn't have to deal at all with buffers. It simply has to care about how often a particular page of memory has been written to (either by memory mapping, or read/write system calls). The original cache in the Linux kernel has the buffer cache. After the page cache was added, things like NFS were immediately built to use it. Older parts, like ext2, continued to use the older buffer cache. Over time, there has been a trend to converting the kernel to using the page cache more often. In Linux 2.2, for example, ext2 used the page cache to do file reads, and only dealt with the buffer-cache for writes. In 2.4, more of the filesystem layer switched to using the page cache for writes as well.

      --
      A deep unwavering belief is a sure sign you're missing something...
    10. Re:Some important points... by be-fan · · Score: 2

      I think you generally want to keep your filesystems about 50-60% full anyway, because ALL filesystems degrade with fragmentation and disk is cheap.

      --
      A deep unwavering belief is a sure sign you're missing something...
    11. Re:Some important points... by sagei · · Score: 2

      Secondly, journalling does not mean that there's no fsck; it just means that it's an order of magnitute or four faster. This is because during the filesystem consistency check, we know *exactly* where to look for problems(thanks to the journal). This doesn't result in better data protection, but it does result in better availability(and hence uptime).

      This isn't true. You do _not_ need to run fsck on a journal partition. A Journal does not simply say "hey the problem is here, just fix these inodes!". A Journal contains exactly what should of happened and what did happen so the inconsistance state can be repaired by "replaying" the not-yet-executed portion of the journal.

      For all intents, you don't need fsck at all. For example, RedHat 7.2 will prompt and ask if you would like to fsck a dirty partition (after the journal replay). Most people say no. If you say yes, most likely nothing will occur since everything is now consistent. It is for the paranoid.

      Ext3 is pretty nice, btw.

      --

      Robert Love

    12. Re:Some important points... by Syberghost · · Score: 2

      And I'm tempted to disregard any arguments that start with something as ridiculously juvenile as "Bzz. Try again."

      Especially if they quote the previous message all in a jumble with their response.

  6. Large file support? by RockyMountain · · Score: 2, Informative

    Question...

    What are the individual file size limits, and overall filesystem size limits for each of the various journalled filesystems?

    I ran into the file size limit on ext2 just recently (2GB, I think it was), and I want to upgrade to something that handles larger files.

    Thanks.

  7. it's really simple by matrix0040 · · Score: 4, Interesting

    well the best part about ext3 is if something goes wrong .. you can convert the system back to ext2 in a second.. just mount it as ext2;-) having said that .. i've been using ext3 for over a year now without any glitch. i had a 30G partition and lots of power failures .. so ext3 really eased my life and converting a current ext2 to ext3 is also pretty simple. no more backup of 30G of data ...

    1. Re:it's really simple by dangermouse · · Score: 4, Funny
      no more backup of 30G of data ...

      You know, ext3 doesn't prevent your disk from bursting into flame or lapsing into seasonal depression and jumping off a cliff or something.

    2. Re:it's really simple by LinuxHam · · Score: 5, Insightful

      no more backup of 30G of data

      I'm hoping by this comment that you're not the same user who's Ask Slashdot just got posted, asking how to become a UNIX admin, cuz this ain't it. It's funny that you should pick that exact number too, because a close friend of mine was shifting disks around in his systems yesterday. At some point he lost track of exactly which hard drive was connected to which ribbon and which IDE port that ribbon was connected to. He ended up running a fresh install of RH7.2 over the 30GB hard drive to which he had "backed up" everything he has collected over the last five years. He called me saying he felt like he was going to throw up.

      I say "backed up" because, as an enterprise systems architect, I don't believe anything is a backup unless it takes at least a little effort to destroy the data. You can't throw a write protect tab on a hard drive. When I traded a P75 system for a 10GB hard drive with the friend above, he gave it to me with over 5GB's of his stuff on it. I backed it up to tape with Amanda, and write-protected the tape. I never thought *he* would need me to restore his data off my tape.

      --
      Intelligent Life on Earth
  8. Those benchy thingies... by trilucid · · Score: 3, Interesting


    Anybody have any real-world benchmarks we can have a look at? I hate to sound redundant on this, but performance is a big issue for web/file servers (which is mostly what I'm running these days).

    If the "running the hell out of it" scenarios look good, I'll probably give it a shot on a production box. Actually, knowing me, I'll give it a shot anyhow, but hey... ;)

    Just as a thought, I'm operating from a starting assumption that it's *pretty much* just ext2 with journaling, but it's the overhead for the journaling that raises my eyebrows just a tad...

    Thanks for the feedback!

    1. Re:Those benchy thingies... by trilucid · · Score: 2


      matt-fu, you are absolutely correct :). See what too much Perl does to you? You start to desperately want answers you could easily find for yourself ;). I need mo' coffee now...

      In all seriousness, upon further consideration of my (parent) post, a certain quote comes to mind:

      "There are lies, damned lies, and benchmarks."

      I seem to recall this being most true of filesystems and databases. Hell, I've got a couple of decent PIII machines not doing much, time to have some fun (perhaps later on, buy new hard drives after my "tests" cause platter issues...).

      Thank you for the reply!

    2. Re:Those benchy thingies... by dbarclay10 · · Score: 2

      Here are some benchmarks, run on a Celeron 300A(@450MHz), 224M of RAM, on an IBM-DJNA-371350. I booted into single-user mode, with absolutely no outside connections available whatsoever. I prepared the test partition with 'dd if=/dev/zero of=/dev/hdc4'. Then I created the FS, rebooted(single-user mode, as I mentioned), mounted the FS on /mnt, then ran bonnie++ without any parameters. Here are the results:

      http://markybobdeb.sf.net/elf/tests.txt

      Kernel used was 2.4.13; first compile without ext3 patch, second compile with ext3 patch and ext3 code hardlinked.

      --

      Barclay family motto:
      Aut agere aut mori.
      (Either action or death.)
    3. Re:Those benchy thingies... by Soft · · Score: 2, Interesting
      I will now retest ext3, since I can't believe this result.

      I wouldn't be too surprised; ext2 by default does completely asynchronous writes, while ext3 is more reasonable and flushes data to disk before transactions commit.

      You may want to mount your ext3 partition with the data=writeback option, which is closer in behavior to ext2, or alternatively mounting your ext2 partition sync. But ext3 has not been thought for high performance, reiserfs probably fares better.

      That said, I'm still using ext3 on my Linux boxes rather than reiserfs as the latter has a history of being unexportable by NFS (something to do with inode management). Now they say it's OK, but I'd have to look a bit deeper.

    4. Re:Those benchy thingies... by 1010011010 · · Score: 2

      I had problems creating symbolic links on an NFS-exported ResierFS filesystem; the symlinks tended to have random garbage in them, rather than a pointer to the file in question. It looked like the symlinks contained bits of other files. It seemed to happen more often in deeper directory structures. Had anyone else seen that behavior with Reiser and NFS? Maybe I should have used the "notail" option, or something.

      Anyway, I converted the filesystem to Ext3.

      --
      Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
  9. Re:Yay! by beable · · Score: 2, Informative
    I hate having to fsck my / partition (which is still stuck in ext2 land because I'm afraid to change it).
    All you have to do is make a tiny /boot partition which can be ext2. Then you can easily use ReiserFS, ext3, XFS, or whatever you want for your root partition. If your system crashes, you would only have to fsck about 15 megabytes or whatever the smallest partition you could use is.
    --
    ...
  10. Is it light on HD requirements? by strredwolf · · Score: 3, Interesting
    I'm on a laptop with a half-gig HD. No, I can't get a larger one because it's an old laptop and I don't have money to buy another. So far, I've crammed a decent install of Slack 8 with X11 onto it with about 150 Megs free on an ext2 partition.



    Reizer leaves me with 100 free



    Is this going to chew up more HD room? I'd love to find a nice, ext2-like file system to make this laptop's root.

    --

    --
    # Canmephians for a better Linux Kernel
    $Stalag99{"URL"}="http://stalag99.net";
    1. Re:Is it light on HD requirements? by Anonymous Coward · · Score: 2, Informative

      It will take a _little_ extra space. The journal is normally a file in the root of each ext3 partition which is untouchable/hidden from all but the kernel.

      The new fstools will create it for you with the -j option to mke2fs or tune2fs, but in the old days we created it with dd and passed it's inode to the kernel by a mount option - but only for the first mount.

      For my partitions of between 250Mb and 1.5Gb, I use a journal of 8Mb and have no problems. A bigger journal will allow more data to be journaled before it fills and a flush is forced, so is more efficient, but for a small disk with no big writes, a 4Mb to 8Mb journal is more than sufficient.

      BTW, the current code allow (I think) off-media journals, so you could use journal across disks, or to a battery-backed ramdisk, or an IDE disk implemented with battery backed DRAM, or SRAM.

      Unfortunately, FLASH disks would exceed their maximum-number-of-writes specification in about a year, based on a write every 30 seconds.

      astfgl@iamnota.org

    2. Re:Is it light on HD requirements? by Scooby+Snacks · · Score: 2, Informative
      Is this going to chew up more HD room?
      Unfortunately, yes. The journal itself takes up some room, and there's no getting around that.

      With ReiserFS, the journal size is 32MB, regardless of the partition size. Apparently, though, the journal size on an ext3 partition is variable, and is just 15MB by default. (Look for "Disk space" toward the end of the page.) See also the man page for tune2fs(8) with a reasonably recent version of e2fsprogs.

      --

      --
      Runnin' around, robbin' banks all whacked on the Scooby Snacks...
    3. Re:Is it light on HD requirements? by Pig+Hogger · · Score: 2, Funny
      No, I can't get a larger one because it's an old laptop and I don't have money to buy another.
      You oughta pimp yourself. One evening as a naked dancer in a gay bar will gross you more than enough to buy yourself a 10 times larger drive for your laptop.

      Or if you can't get yourself to dance naked in front of drooling geezers, a few blowjobs administered to the same geezers in the john or the parking lot will do the trick.

    4. Re:Is it light on HD requirements? by Pinball+Wizard · · Score: 2
      You are amazing. Anyone who can post such enlightened offerings at +2 is obviously a True Master(TM).


      And by the way, all you young but poor college students. Why live on ramen and work at a substandard computer? Take this guys advice!

      --

      No, Thursday's out. How about never - is never good for you?

    5. Re:Is it light on HD requirements? by strredwolf · · Score: 2

      The Compaq LTE Lite 4/33C had a 200 meg drive I replaced with the half-gig. Any more and it looks like I need a new BIOS. Thankfully I can flash one in, but it's the latest I can get from Compaq. :P

      I also have a 1 gig, but it doesn't work in the system (it doesn't recognize it).

      --

      --
      # Canmephians for a better Linux Kernel
      $Stalag99{"URL"}="http://stalag99.net";
  11. GNU/ext3fs by Anonymous Coward · · Score: 3, Funny

    GNU/ext3fs

  12. Finally! by Enahs · · Score: 2

    ext3 was just about the only reason I was using -ac kernels...

    --
    Stating on Slashdot that I like cheese since 1997.
  13. Source Forge uses ReiserFS by brinkster · · Score: 5, Insightful
    Not sure how new this is but a quote from someone at Source Forge on the ReiserFS site.

    http://ftp.sourceforge.net/ has 850GB storage, half of which is reiserfs, half is ext2. Both filesystems have been running flawlessly for > 4 months of production (actually longer, but wasn't reiserfs before). That server pushes between 15Mbit and 50Mbit/sec, and pulls/syncs about 2-5Mbit/sec, 24x7. reiserfs also powers the CVS tree filesystem for cvs-mirror.mozilla.org (also tokyojoe.sourceforge.net), which is the one and only anonymous CVS checkout point for mozilla. That server has run flawlessly under very heavy load since its birth. I don't get involved in kernel politics, but as a production filesystem, reiserfs is ok in my book.

    1. Re:Source Forge uses ReiserFS by cabbey · · Score: 2

      Not sure who that quote came from, but anyone claiming cvs-mirror.mozilla.org has run "flawlessly" is full of it. While it's problems may not be filesystem related, the box ISN'T perfect.

  14. Re:can somebody tell me.. by Mendax+Veritas · · Score: 2
    People have been using ext3 in production for some time, without difficulty, so your expectation is heading for serious disappointment.

    I remember reading somewhere a while back that Linus and other kernel developers were disinclined to ever put XFS in the kernel because it was a huge amount of code and pretty ugly.

  15. Re:Forgive my ignorance, here... by PlaysWithMatches · · Score: 3, Informative

    Here's a quick explanation of a journaled filesystem, courtesy of LinuxPlanet.com:

    The term "journaled" means that the filesystem maintains a log or record of what it is doing to the main data areas of the disk, so that if a crash occurs it can re-create anything that was lost.

    ...

    The idea is that the system can crash at any point in this process but that such a crash won't have lasting effect. ... So when the system reboots, it can simply replay the journal entries and complete the update that was interrupted, or it can back out a partially completed update to restore the file's previous state. In either case, you have valid data and not a trashed partition.

    Basically, it means no more long disk checks at startup after a crash or power outage. :) And it virtually eliminates disk fragmentation too, I believe. Hope that helps.

    --

    Mozilla's a nice operating system, but it needs a better browser.
  16. Journalling for the unshaven masses? by Scooby+Snacks · · Score: 2, Interesting
    Well, I don't know about that. I've been using ReiserFS since about 2.2.17 or 2.2.18, and it's worked great. It was officially integrated into the kernel in 2.4.1 (at the end of January this year), and distributions started incorporating it soon after. (Actually, before that, if I'm not mistaken. I was installing my work laptop last November, and the then-current version of SuSE supported creating ReiserFS partitions during the install even then. Wound up going back to Debian, though.)

    So journalling's been available to the masses for a while now. Or maybe Michael meant ease of converting for the installed base?

    Now if only the damn preemptible kernel patch would make it in. Unfortunately, it looks like that's going to wait until 2.4.5. *sigh*...

    --

    --
    Runnin' around, robbin' banks all whacked on the Scooby Snacks...
  17. ext3 or ReiserFS or XFS - is this the question? by Auka · · Score: 2, Offtopic

    Ok, I can already hear the Trolls arguing which FS is superior.

    Personally I'd say that it depends and it is not the point asking whether one should use ReiserFS, ext3 or XFS.

    Personally I've been using ReiserFS for ages without ANY problems at all on a number of systems running SuSE, Mandrake 8 and recently on RedHat 7 and 7.1. Over the time I've been more than satisfied with the results I got regarding speed, stability and so on.

    But personally I'd really like to be able to freely choose which FS to use - I really can't understand why especially redhat was ignoring ReiserFS all the time, claiming (IMHO you can't otherwise say so!) it was "unstable". This must be some kind of weird "political" or strategic question.

    So my 2c: at least leave the average user the ability to choose his preferred filesystem in Distro setups and don't just simply stick to one and ignore the others as if they wouldn't exist- nobody will complain if it's set to ext3 by default for beginners. ;)

    1. Re:ext3 or ReiserFS or XFS - is this the question? by norton_I · · Score: 2

      I have been using ResierFS for a few months now, and for the most part, it has worked well.

      But the lack of a fsck is inexcusable. I have has a couple of "events" which might have corrupted a filesystem (my fault, not resierfs'), but had no way to check. Once, I went through my partitions one by one, copied them to a temp partition, mkfs'ed them, and copied them back. I put up with it because it was a pain in the butt to switch. Now that ext3 is in a Linus kernel, I am seriously considering running some tests, and converting back.

  18. Linus on preemptible kernel (and Tweedie on ext3) by kingdon · · Score: 5, Informative

    Someone asked Linus about the preemptible kernel patches (and latency in general) at the Annual Linux Showcase on Thursday night. The thing about the preemptible kernel is that it is only for uniprocessor - SMP kernels aren't preemptible. So unless you want the SMP case to be capable of tying up a processor for "too long" at a time, then you need to re-do each bit of code which is capable of long latencies anyway. The other thing which came up is that responsiveness of the system improved quite a bit recently with VM fixes (2.4.14 was the improved version, I think). It was a matter of the VM queueing up too much I/O (and the drivers trying to throttle it, instead of just throttling it all in the VM - or something like that). The preemptible kernel won't solve that kind of problem - although it may change/mask the symptoms enough to make it a bit hard to be sure where a problem is.

    Oh, and to bring things back to ext3, Steven Tweedie was also there and made a number of comments about ext3. He has been fairly busy/nervous lately as ext3 just got into the hands of Lots Of(TM) users (when it shipped with Red Hat 7.2). The most serious problem I remember him talking about was that the 7.2 installer had a box marked "upgrade my ext2 to ext3" and one marked "makefs the filesystem" (or something like that), and some people were checking both - which would create a nice new empty filesystem in place of the one which was being "upgraded". But of course that is just user error plus a confusing installer, not a kernel problem. Most of the things which looked like ext3 kernel problems seem to be something else, as far as Steven has been able to tell so far.

  19. ext2 limit graph by Anonymous Coward · · Score: 4, Informative

    The ext2/ext3 limit is 4 terabytes, but Linux
    device files have a 1 terabyte limit.

    http://www.cs.uml.edu/~acahalan/linux/ext2.gif

    Pay attention to the note on the right.
    That explains why apps often break at 2 GB.

  20. Re:can somebody tell me.. by ochinko · · Score: 3, Funny
    Why Linus chose ext3 over the more proven technology

    Perhaps this is Linus' way of saying: "Ok, Alan, I'm sorry about the VM. Are we even now?"

  21. I wish Linus would stop this by Billly+Gates · · Score: 2, Troll

    I have nothing against the ext3 filesystem or the new virtual memory patch but Linus needs to stop adding these relatively radical changes into the so called stable kernel reserved only for drivers and bug fixes. The issue is not that big for most hackers reading this but alot of us run Linux on mission critical servers that we bet our jobs on. Even before the radical kernel patches, all the newer kernels had big-time showstopper bugs. Many admins even run the old 2.2 kernel to avoid unnecessary problems. I have been running 2.4 and had no problems yet luckily. However I really do not know if I can recommend Linux as a server OS anymore. I want stability and Freebsd and Solaris seems to meet my needs alot more. Hopefully this madness will stop soon. We all love to bash Microsoft for releasing buggy service packs for NT that have not been tested thoroughly but there seems to be no real testing with Linux kernel patches. Freebsd conquered this problem by having 2 development teams. One for the stable branch and one for the development branch. No radical changes are allowed in the stable branch and the stable branch must go under lots of testing to be approved to be released as stable. I now know why BSD hackers love there development model. Cutting edge is great for some users but please do not include it in the kernel where a lot of people count on it for servers and mission critical applications.

    --
    http://saveie6.com/
    1. Re:I wish Linus would stop this by Jagasian · · Score: 2
      No radical changes are allowed in the stable branch and the stable branch must go under lots of testing to be approved to be released as stable. I now know why BSD hackers love there development model. Cutting edge is great for some users but please do not include it in the kernel where a lot of people count on it for servers and mission critical applications.
      Yeah, the Linux equivalent is called Debian Linux. You can run the main or stable branch of the distro, and while you give up bleeding bloody edge software, you gain stability and reliability unheard of in Redhat land. There is more to this world than Redhat based Linux distros (Debian, etc...). Just as there is more to this world than Linux (BSDs, etc...) The software is free and runs on nearly everything, so you have no excuse for not giving alternatives a try.
    2. Re:I wish Linus would stop this by psamuels · · Score: 2, Insightful
      Linus needs to stop adding these relatively radical changes into the so called stable kernel reserved only for drivers and bug fixes.

      Think of ext3 as "only a driver" -- which in your book is OK for a stable kernel. In terms of how much the code disturbs the rest of the kernel if you don't compile it in -- it really doesn't, just like a driver.

      The VM change in 2.4.10 -- there I agree with you. (As does Linus, apparently, as he later admitted.)

      --
      "How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
    3. Re:I wish Linus would stop this by cvanaver · · Score: 2, Informative

      A) No one is forcing you to upgrade. If you are throwing the bleeding edge onto Prod servers you deserve what you get. That doesn't just apply to Linux, it applies to Solaris, AIX, HP-UX, Windoze and everything else. Get a clue.
      B) At least Linus isn't terrified of making changes to the existing code base and fixing inherent problems, regardless of his testing base. I just ran into an issue on Solaris where as we had a middleware daemon (TIBCO Rendezvous) which hit upon a rather serious flaw in 32-bit Solaris where it could not resolve more than 256 calls to alias a port/service. At 257 the call to resolve a service alias would just fail. We talked to Sun about it and they said they knew it was an issue an refused to change it (ever) cause it would require them to change a foundation C struct that might break a bunch of apps. I understand Sun's viewpoint, but they have taken the 'safe' approach where they are locked into code limitations of the past. Great, so I get stuck with un-documented bug-crap forever.
      C) Linus is the visionary, not the tester. If you don't trust RedHat or others to test the upgrades, and you don't have the desire/bandwidth to do it yourself, then you either shouldn't be running Linux or shouldn't be considering upgrades.

    4. Re:I wish Linus would stop this by BlueUnderwear · · Score: 2
      A) No one is forcing you to upgrade. If you are throwing the bleeding edge onto Prod servers you deserve what you get. That doesn't just apply to Linux, it applies to Solaris, AIX, HP-UX, Windoze and everything else. Get a clue.

      True, as long as the kernel is labeled "bleeding edge". As far as I understood, that was what the even/odd numbering was for: 2.3.x, 2.5.x unstable, but 2.2.x and 2.4.x stable. "Even" kernels are meant to only receive bugfixes or rather peripheral additions (new drivers, yes, and also new filesystems), but no fundamental changes (new VM...).

      If this had happened during 2.3.x, nobody would have complained. People even don't expect the 2.3.x kernels to compile... After all, this is what the development branch is for. But on the other hand, such changes have no place in the so-called stable branch.

      --
      Say no to software patents.
    5. Re:I wish Linus would stop this by cymen · · Score: 2

      Then a new release came out, and I wanted to upgrade to it. It took well over an hour, pretty much all of which required my attention.

      What took the majority of the time? So far I've upgrade from 4.4-RELEASE to 4.4-STABLE and it was very smooth. The only thing I could see taking a long time is doing the mergemaster to merge in config changes. But even that I can't see taking a whole hour... The compile time might be a bit lengthy for buildworld but that is unattended.

  22. ReiserFS by Sludge · · Score: 2
    Well, when I installed slackware 8, I pulled a few tricks out of my hat to use ReiserFS. So far, it's been flawless for my rather normal needs. The few times I've gone down, I came back up with no problems.

    So, mark one vote of confidence for reiser.

  23. Uh, No. He's Adding Support, Not Replacing ext2 by Lethyos · · Score: 4, Insightful

    Okay, if you have a set A with N elements, and you add an element to the set such that set A now has N+1 elements... well, that doesn't change the original 0 through N elements.

    Your complaint can be applied to the case of adding driver support to an existing kernel. You see, in the life of a kernel, time passes. As time passes, new hardware, software, algorithms, etc. come out. In order for us to keep modern, we have to add new things to the existing set. You're just... silly.

    Going back to my original statement, the new virtual memory subsystem wasn't an addition. He was removing an element from the set and replacing it with something different. That could be argued as bad, but in practical terms it ended up perfectly fine.

    Furthermore, if you had done any homework, you'd have realized that ext3 is built using hooks that have been available in ext2 for years. Technically speaking, ext3 is as stable as ext2 because the fs can still function as ext2 if ext3 support goes away or breaks.

    So stop bitching about support for new things being added to the kernel. We could only be lucky if new features were added faster. At the very least, stop dumping FUD on us. Your alias is so very appropriate in light of your post.

    --
    Why bother.
  24. Ugh... More FUD From Within... by Lethyos · · Score: 4, Insightful

    An important factor in Linux' cost is its maintenance. Linux requires a *lot* of maintenance, work doable only by the relatively few high-paid Linux administrators that put themselves - of course willingly - at a great place in the market. Linux seems to be needing maintenance continuously, to keep it from breaking down.

    You're off your rocker. Linux boxes have to be admin'ed ONCE in a big way, then they just keep working after that. You've mistaken it for NT, which BREAKS constantly and requires constant attention. I have a Linux server sitting in my closet that I haven't touched for months. It just works and gets heavy use. Not to mention that when used properly, *nix solutions have a constant maintenance cost, while NT solutions require growing fees. What do I mean? With *nix, you have one central box that needs adminning, and all your clients get their apps, configuration, and data from that box. So, if you have N machines, you have 1 box to admin. With NT, every seat has to have its own apps, data, and configuration. You multiply your work load by a factor of N. So, if it costs C dollars to admin one machine, NT costs C*N, while properly implimented *nix solutions are C.

    Add to this the cost of loss of data. Linux' native file system, EXT2FS, is known to lose data like a firehose spouts water when the file system isn't unmounted properly. Other unix file systems are much more tolerant towards unexpected crashes. An example is the FreeBSD file system, which with soft updates enabled, performance-wise blows EXT2FS out of the water, and doesn't have the negative drawback of extreme data loss in case of a system breakdown.

    More nonsense. ext2 will lose data if the data isn't written to the disk when a failure occurrs. So will UFS. But you won't experience corruption of data you're not working with otherwise. ext2 is stable and solid. It gets corrupted if you fuck with it. Same goes for every other fs.

    According to Linux advocates, an alternative to EXT2FS would be ReiserFS. Unfortunately, ReiserFS is still in beta stage. This means it is not intended for production use (although according to many Linux advocates this shouldn't be a problem, which makes me wonder how (little) valuable they find your data).

    ReiserFS isn't in beta. It's sufficiently stable and is used by lots of people on production machines.

    The other proposed 'solution', EXT3FS, is nothing more than an ugly hack to put journaling into the file system. All the drawbacks of the ancient EXT2FS file system remain in EXT3FS, for the sake of 'forward- and backward compatibility'. This is interesting, considering that the DOS heritage in the Windows 9x/ME series was considered a very bad thing by the Linux community, even though it provided what could be called one of the best examples of compatibility, ever. When it's about Linux, compatibility constraints don't seem to be that much of a problem for Linux advocates.

    Uh, no. Backwards compatability is good if the older stuff is still used. Also, the backwards compatability in ext3 does not break its implimentation. DOS is dead and burried. There was no reason to keep support for it lying around, but MS did anyway and it was responsible for a LOT of the instability in Windows 9x/2000. People still using DOS stuff, should not be upgrading. Microsoft just forces them to. Not only that, ext[123] was designed to be EXTENSIBLE, something Microsoft idiots don't seem to understand. Extensiblility is about being able to add future functionality without rewriting or breaking a package. Hooks exist in ext that let you add new features. This is a Good Thing.

    Back to Linux' cost. Factor in also the fact that crashes happen much more often on Linux than on other unices. On other unices, crashes usually are caused by external sources like power outages. Crashes in Linux are a regular thing, and nobody seems to know what causes them, internally. Linux advocates try to hide this fact by denying crashes ever happen. Instead, they have frequent "hardware problems".

    I'd like to see some statistics. This claim is unsubstantiated. I've seen Solaris boxses drop like flies. However, most Linux boxen I've ever used have been VERY stable and once everythings up and running, it flies smooth for months even years at a time. If "Linux" crashes (what you think is Linux crashing, is actually XFree86 or Mozilla), it's usually recoverable. Don't confuse your lack of knowledge with Linux being unstable.

    The steep learning curve compared to about any other operating system out there is a major factor in Linux' cost. The system is a mix of features from all kinds of unices, but not one of them is implemented right. A Linux user has to live with badly coded tools which have low performance, mangle data seemingly at random and are not in line with their specification. On top of that a lot of them spit out the most childish and unprofessional messages, indicating that they were created by 14-year olds with too much time, no talent and a bad attitude.

    This is pathetic. Linux makes things at the system level easier for most users to understand. You're saying that, say, /dev/hda4 is easier to understand than /dev/ct0s1r4? Also, you're saying that the typical utilities are unreliable? Where's your support? Notice many commercial Unixes (not "Unices"... Unicos is Cray's OS) are moving to GNU utilities? Ugh... this complaint is so unsubstantiated I can't even level a structured retort!

    I could go on and on and on, but the conclusion is clear. Linux is not an option for any one who seeks a professional OS with high performance, scalability, stability, adherence to standards, etc.

    You're right. Windows is much more stable and reliable. Oh yeah, and Solaris is much cheaper and secure. Forget free software. It sucks. I mean, it's worthless, because it's free, right? I mean, why would it be free if it was good? Anything that's good is worth paying millions for.

    You're so hopelessly confused that I can't tell if you're a Windows luser/wadmin or a pro-BSD zealot that doesn't even use BSD but read about the fights between the two camps. Maybe I'm juts feeding a troll here, but I gotta battle the FUD.

    --
    Why bother.
    1. Re:Ugh... More FUD From Within... by krogoth · · Score: 2

      You know, I think I agree with him that Linux isn't perfect - I have my linux server, and it's just there! It's boring because it never crashes (although I did once chmod the root directory -x and didn't notice for a few days). I actually have to download stuff and try new software if I want to use it! Linux is too stable for me, I want something that demands to be used every day!

      --

      They that quote Benjamin Franklin on liberty and safety deserve neither.
    2. Re:Ugh... More FUD From Within... by Lumpy · · Score: 4, Interesting

      as a good example..

      I have 1 linux box that is only accessable via Packet radio. It is currently about 250 feet in the air and about 35 miles away running on a 386 1/2baby motherboard (tiny mobo, almost a sbc too.) I installed in 1996 for the local ham radio group. It acts as a packet repeater/packet BBS and runs off of a Solid state IDE disk drive (A whopping 20 megabytes!!!)

      It runs Kernel 1.2.5 from a reallly old yggdrasil distribution.

      It hasn't been touched cince and has only rebooted because of power failures.

      Linux is so horribly stable that it has worked flawlessly without attention for 6 years...

      I dare anyone to show me a windows/dos/Xenix install that can do the same. Would you put it in a place that makes it basically impossible to get to without hiring someone at $290.00 an hour to bring it back down to you.

      --
      Do not look at laser with remaining good eye.
    3. Re:Ugh... More FUD From Within... by Od1um · · Score: 2, Informative

      Both io.sys and msdos.sys are 0 byte files.. looks like there's lots of DOS stuff in there.. They're there so old programs that look for them will still run.

      >Worse, try deleting these files and see what it gets you. Then try to do a repair install... oh my. They aren't put back... muahahahaha!

      I gave you the benefit of the doubt and deleted them to see what would happen, and then rebooted. Win2K started up with no problems. It didn't recreate them, but I'm posting this with no problems, so obviously they're not very important (which would make sense considering they were 0 byte files).

      Command.com is there, but it doesn't run natively - notice the extremely slows peed compared to the native NT command line program 'cmd.exe'.

    4. Re:Ugh... More FUD From Within... by SmittyTheBold · · Score: 2, Informative

      There was no reason to keep support for it lying around, but MS did anyway and it was responsible for a LOT of the instability in Windows 9x/2000.

      Just FYI, DOS was gone in the "pro" MS OSes for years. There is no trace of it in NT, 2000, or XP.

      2000 is actually quite stable in a production environment. It may not be as stable as a properly stripped-down and customized Linux install, but it's pretty damn close. It manages to do that with a good bit more user-friendliness.

      Backwards compatability is good if the older stuff is still used. Also, the backwards compatability in ext3 does not break its implimentation.

      The old stuff in DOS was still used by some people, that's why it's there. You know what? Much of Linux is not so much binary compatibility with previous releases, but it's idea compatibility with ancient software. If I was writing an OS from scratch, you can bet I would not target source compatibility with 60s software as my primary goal. That's what Linux is - a clone of old software. I find it quite amusing all these people insist Linux is the future, when all it really tried to do was emulate the past.

      Back to filesystem design - just because it's still used, doesn't mean it should stay in use. You have to keep using something while the new it brought in...but justifying software's existence by the fact it's in use is the exact argument MS uses. EXT2 is dead. EXT3 is a hack on top of EXT2 to make it slightly more modern. Think of it liek Windows 3.1 on top of DOS. Now you get it. We need something new, and there are filesystems coming that will be the new thing. If you want to see where the Linux FS scene will be in a few years, look at BFS. Journalling, attributes, 64-bit, you name it. EXT3 only does a little of what an FS will have to do in the future. Don't ignorantly assume because somethigg can still be useful now it will be useful in the coming days.

      --
      ± 29 dB
    5. Re:Ugh... More FUD From Within... by spitzak · · Score: 2
      Unix was considered a significant change from software design in the 60's. It made devices look like files, byte addressed the files, had hierarchial directories, had a very small run time library, multiple processes with exec and fork, and a lot of other stuff that was very ground breaking and really made it popular. In some cases people who first encountered Unix were absolutely floored by the incredible increase in simplicity and programmer power (I was).

      Part of the absolutely rabid hatred of Windows is that there is pre-Unix stuff leaking back in. This is because Windows comes from DOS and that comes from CP/M, which is mostly influenced by RSX-11M, a 60's operating system. A typical example is the use of ^M^J for line breaks, this is based on the mechanical requirements of Teletype printers (where the motor was not strong enough to move the printhead and advance the paper at the same time, you can believe me that when communication was 110 baud there was no other reason to add one byte to every line!!). Other things are time stamps in local time (obviously stupid for networks) and case-independent filenames which make I18N impossible without security problems. In general this is all crap that should not be done by the underlying system (for instance case-independent filenames would be better done by a user-level matching algorithim that could correct spelling errors as well).

      I would agree that Unix has not shown much great advances since about 1980 or so. But a lot of the problems are a refusal to use the "old" stuff. Unix started to turn into a mess when they started making file types that could not be named or created with open().

    6. Re:Ugh... More FUD From Within... by Lumpy · · Score: 2

      I dare anyone to try and crack it. Hell I'll give them $200.00 in cash to do it..

      you'd have to crack the Packet radio software to drop to to a root shell or transfer software to it... Oh wait, as soon as you crash the software it's impossible to do anything as the commuinications depend 100% on that software.

      No I dont use the built in kernel ham radio stuff, that's just plain stupid to use if you have one specific use.

      It's insecure if you use the insecure parts, if you dont use the insecure parts (like TCP/IP networking, or networking in general) and use telemetry system and other forms of communication it's perfectly fine. I'd put the same disk image on a sattelite in a heartbeat and thumb my nose at anyone that would reccomend a non-extensively-tested kernel. (Anything in the 2.XX is not tested enough for a sattelite or space based craft.)

      It's how you work around the limitations of the O.S. dont give a hacker a door and he cant come in.

      also, any attacks are very obvious, 1200BPS on a public non encrypted frequency would be noticed easily. and tracked within hours. my whole point was stability.. I have concrete proof that linux in the 1.2.x iteration is probebly one of the most stable OS's on the planet available to consumers. In fact I read in a linux journal 4 years ago that that kernel branch release was used for data collection stations in the antartic, where people cant get to them for years at a time... Something microsoft cannot do... ever.

      so yeah, it may have a vunerability, but it will not affect anyone that takes care of eliminating cracker access in the first place.

      --
      Do not look at laser with remaining good eye.
    7. Re:Ugh... More FUD From Within... by Lumpy · · Score: 2

      Ok, Montcalm county, MI
      142.550 Megaherts
      No PL tone. 1200bps
      if you dont connect with a Callsign in your TNC identifier string it ignores you. Also, if you dont have a callsign that has connected before you have almost no access until you submit information to the system that is then reverse verified.

      Good Luck! we're all counting on you.

      --
      Do not look at laser with remaining good eye.
  25. ReiserFS kills interactive performance by Anonymous Coward · · Score: 2, Interesting
    I've been using ReiserFS since about a month after it went into the standard 2.4 kernel tree, since I wanted a journalling filesystem. At first I just used it for /usr, and it worked great. There was a noticable performance increase accessing large directories (like /usr/share/doc), and it saved some space. A few months later I converted /home. It works OK normally, but when copying large files, the system becomes entirely unusable. The mouse pointer lags noticeably (it jumps across the screen in 100-pixel intervals), my 4-second XMMS buffer is emptied and my music stops playing, and the system load jumps to somewhere between 3 and 5. This is on a 1GHz P3, and DMA is on. I had the same problem on my 700MHz P3, with a different motherboard, but I never had these problems with ext2.

    The problem is that writers starve readers on ReiserFS. When writing a lot of data (for example, copying an MP3 album or a movie), no processes will be able to read from that filesystem. It's a known problem in the ReiserFS FAQ, but they really downplay it's severity. If you regularly work with large files, or copy large groups of files (more than ~50MB), stay away from ReiserFS.

  26. Re:One thing I like about ext3fs... by tap · · Score: 2
    What does beowulf clustering have to do with ext3? Nothing! Someone should have modded your post (+1, Buzzwords).

    There are filesystems designed for beowulfs, like PVFS, which let you take the hard drives in a bunch of computers and merge them into one big filesystem. But ext3 has nothing to do with this.

  27. Re:FreeBSD by cperciva · · Score: 5, Informative

    FreeBSD doesn't need a journaling file system: FreeBSD has softupdates, which ensure that the filesystem metadata is always in a consistent state while providing better performance than journaling.

    --
    Tarsnap: Online backups for the truly paranoid
  28. ext3 and quotas.... by weave · · Score: 4, Interesting
    I'm trying to decide whether or not to convert a production system I manage that has 16,000 user accounts connected to a 1 terabyte EMC SAN. I've done a lot of searches and turned up some troubling posts about ext3 when it comes to using it with journaling and quotas turned on.

    It's like what's worse, dealing with a fscks that seems to take hours or increasing the risks of more crashes but at least you get back up faster. I can't live without quotas either. Can you imagine a student in a lab with a 10 Mbps connection to the Internet and a few hundred gigabytes of writable space? :)

    It's starting to look like I can't have my cake and eat it too. :(

    I'm glad Linus is blessing it. Hopefully the issues will be resolved soon. Until then, maybe redhat jumped the gun including it in their distro...

    1. Re:ext3 and quotas.... by selmer · · Score: 3, Informative

      It looks like there are still some quota-problems with the Linus-kernels, check this post on the ext3 user-list, in which which Andrew Morton says that there are no known quota-problems with the ac-kernels but that he wants to test a bit more on the Linus-kernel as it used to cause deadlocks.

    2. Re:ext3 and quotas.... by be-fan · · Score: 2

      Why not use XFS. Sure its doesn't have holy penguin pee all over it, but I haven't heard about any stability problems with it, and its support for pro level servers (even on Linux) seems to be quite good.

      --
      A deep unwavering belief is a sure sign you're missing something...
  29. What? I didn't see any musos getting eaten by leonbrooks · · Score: 2

    ...nor did I hear an explanation of how this wound up in a 2.4.* kernel instead of 2.5.*, where right now it really belongs, even though AFAICT it's dead stable.

    --
    Got time? Spend some of it coding or testing
    1. Re:What? I didn't see any musos getting eaten by baptiste · · Score: 4, Interesting
      how this wound up in a 2.4.* kernel instead of 2.5.*, where right now it really belongs,

      Heck if we can swap out the VM midstream, this is nothing :) Actually I think Linus was VERY smart to push the new VM into the kernel. Why? Because I believe he avoided a LOT of people running patched kernels until 2.5 was released. It was obvious the 2.4 VM was broken. Had he held off, folks would have realized (though probably slowly) that the new VM was better and they'd have patched it in anyway.

      The same holds true for ext3. RedHat is already shipping it with RH 7.2. Its rock solid from their standpoint. So it makes sense to include it in the stable kernel. Sure, we all wish Linus had the ESP ability to have known to include these things at 2.4.0 (wait the new VM didn't exist then :) ) but given current circumstances, these are smart moves. Otherwise we'd all be patching kernels for another year to get ext3 (if we wanted it) and the new VM.

      Yes, I realize patching kernels is a fact of life - I do it all the time to get XFS for my desktops and servers, but the less patches I need to worry about the better.

      We can stick our noses in teh air and talk about how Linus never let big feature patches into the kernel before - well, everyone is allowed to change their mind. Besides, its not THAT huge a deal. If you're worried about stability, stick with what works. But if you need newer features for your setup, you can use a more recent stable kernel.

      In the end, this ensures stuff in high demand sees production use earlier. If we waited to 2.6, you'd just be delaying it to far, not just for the new kernel development time, but also the 'I can't use 2.6.0 in a production box) so you'd wait until a later release. Just like you've waited to deploy 2.4.x production, right? :)

      Things change. RIght now, I'd say for the bulk of the production systems, the smart move is to wait until Linus hands the kernel off for maintenance. Once that happens it'll see MUCH less churn. Befure we had 2 release stages... 2.x where x is odd for development, 2.even#.low# for release beta, and 2.even#.big# for stable production ready kernels I think thats a good thing. Besides its all relative - saying Linus shouldn't put x, y, z in the kernel because the last number is too high is pointless. We just need to adjust to the new release schedule!

      I'm glad 2.4 has what it has. Now hopefully 2.6 will have XFS and I can run vanilla kernels again (nah - never gonna happen :) )

      --
      Top Most Bizarre/Disturbing Error Messages
    2. Re:What? I didn't see any musos getting eaten by baptiste · · Score: 2
      Ugh - really wish that edit feature was in slashcode :) I never seem to catch them all in Preview!

      What I meant to say in the paragraph near the end was we used to have a two stage release cycle: 2.odd for development and 2.even for stable prodcution, now we have a 3 stage release. 2.odd for development, 2.even.low# for large scale beta test and late features, and 2.even.high#/maintenance handoff from Linus for production stable releases. I think the latter is a good thing.

      --
      Top Most Bizarre/Disturbing Error Messages
    3. Re:What? I didn't see any musos getting eaten by Error27 · · Score: 2

      I think it's fine to put it into 2.4

      1) People are already using it and it seems stable

      2) Alan already had it in his tree.

      3) Putting it in makes life easier for Marcelo Tosatti. If Linus and Alan both agree that it should be in the kernel then people think it probably should be. If Marcelo includes ext3 on his own, people would question his judgement. On the other hand if Marcelo leaves it out and Alan stops producing his -ac tree then people who have been using ext3 will be upset.

      4) Ext3 doesn't change anything.

      5) You still can use ext2 if you want.

  30. Steady as a rock by leonbrooks · · Score: 2

    The only time I've ever seen it upset was when someone ran zgv at the same time as XFree86v4.1 (on a CyberBlade-based mobo video) and caused a hardware insanity then lockup while they were writing config back to /etc... ugh...

    --
    Got time? Spend some of it coding or testing
  31. What about 2.5.x? by Cryptnotic · · Score: 2, Informative
    Shouldn't this REALLY REALLY be in Linux-2.5.x? What ever happened to the old mantra "odd numbers, development, new features; even numbers, stable, bug fixes"? Has Linus forgotten? First, completely changing the virtual memory system in 2.4.10, now this.


    Cryptnotic

    --
    My other first post is car post.
  32. Tip: Root partition not being mounted ext3? by Spoing · · Score: 4, Informative
    If you're converting from ext2 to ext3, update /fstab so that 'auto' is used instead of either 'ext2' or(!)'ext3'. Auto makes it easy to dynamically switch to a kernel that doesn't support ext3.

    Unfortunately, if your file system tools aren't upto date, your root partition won't be mounted ext3. A quick check to see if everything worked is to look at the output from either df or /proc/mounts like this;

    1. df -T

    In the second column, it should report the filesystem type of each mounted partition. If you don't see / , you should upgrade fileutils.

    1. cat /proc/mounts

    This is basically how your fstab is currently interpreted, as recorded in /etc/mtab.

    If either of these look wrong, check the kernel sources for Documentation/Changes, and verify that you are using the supporting program versions mentioned in the Current Minimal Requirements section.

    --
    A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
  33. History of kernel video drivers by maynard · · Score: 4, Interesting
    Um, I was once told to (and subsequently did) install Linux on my main machine in 1996, when I was told that regardless of a bad video driver, the drivers themselves never enter protected memory space and shouldn't bring down the system. (I argued that the display drawer itself may crash, but no one seemed to agree with me).
    Back then you were told right. In 1996 you were likely running a kernel 2.0 based distribution with Xfree86-3.x.x. At that time the XFree project wrote separate X servers for specific video chip set support with no integration into the kernel. Mind you, the X server still ran SUID as root, and had control of the console, so a crash might not take down the entire system (networking, disk, and VM would still be up), but the net result could be a hosed console requiring a reboot anyway.

    At the time Linus was staunchly against integrating video support into the kernel as a general device driver, even though an ongoing project called GGI (General Graphics Interface) had written a proof of concept video kernel module, supporting libraries, and an X server. Their system prevented these kinds of crashes by providing an abstraction API layer for applications to access the video hardware through the kernel, just as DRI does today, instead of having individual applications responsible for writing to the hardware directly. The argument then was that no userspace application should write directly to hardware considering the potential for race conditions, security problems, etc. And since all other hardware has an API layer through to the kernel, why not video?

    This concept won out, but not the GGI project. Which is too bad because they had a good idea and a working system back in '96. I'm sure there were some politics involved, maybe a project lead at GGI pissed Linus off or something. I wasn't paying enough attention at the time.

    Just a note about this in comparison with NT: the idea is to abstract out video acceleration routines into a hardware independent API for programmers. In NT 4.0 (which was current at the time), Microsoft placed not a video hardware acceleration API into kernel space, but much of GDI (their windowing system API). Many people thought this was unnecessary kernel bloat and complained vociferously about it being a prime cause of NT 4.0's instability. I'm not an NT programmer, nor do I know much about it's internals, so if anyone wishes to chime up and offer a better explanation please feel free.

    One last point: now that DRI provides a direct kernel interface to video hardware, it's quite possible to take down an entire system with an errant DRI kernel module. Yup -- exactly the same kind of problem that linux advocates used to sneer at NT users over. The NVIDEA GForce proprietary DRI kernel modules are a prime example of problem drivers crashing people's systems. Ironic, huh?

    Cheers,
    --Maynard
    1. Re:History of kernel video drivers by AndyS · · Score: 2, Informative

      Nvidia's drivers aren't DRI. They use their own approach, and have a much larger kernel driver. I use (at the moment) a Radeon DRI driver, and it's very solid, albeit slower. The amount of actual kernel code used in DRI is tiny, unlike the nvidia code (which was unbelievably huge)

      Aside from this, as I understand it, due to the design of PCs, it's not impossible to stop anything that directly writes to your graphics card from screwing it up, as your graphics card can do exceptionally unpleasant things to the rest of your machine. DRI is meant to have lots of checks to try and avoid nastiness happening to your kernel from your video card, and apparently it seems to work.

  34. I can attest to that by Ender+Ryan · · Score: 3, Interesting
    The stability of ext2 I mean.

    I have a tiny box at my home that I use as a router. It's a couple years old now. The box itself is a P100 with all the guts inside loose and hanging all over the place. The HD is > 5 years old and is loud and very unstable, simply doesn't turn on sometimes.

    This little machine stays up 24x7 and only goes down when the power goes out, which is at least once a week here. After a power failure, the drive usually doesn't turn back on until the machine is power cycled and sometimes the whole machine will not turn on... and sometimes requires a light smack ; )

    Even though this little box is a piece of dying crud, after it powers up properly it fscks and boots linux in about 1 minute and works every time. It has NEVER failed to boot after powering up properly after years of constant use. This Linux install is years old, running an older 2.2 kernel and has required absolutely 0 maintenance, other than smacking the machine to get it to power on ; )

    At work we have... haven't counted in a while... say 20 odd machines. About half of them are servers running Linux and 1 BSD box, which do not require any routine maintenance. The other half are running W2k and require constant maintenance. Even if Windows was free, for our small company the TCO would STILL probably be about 3 times that of Linux or BSD. It is simply unacceptable how much time and energy we've had to put into fixing NT and W2k boxes.

    Of course, no matter what anyone here says, there will still be people who adamantly claim that NT/2k/XP require less maintenance and have a lower TCO than Linux/BSD and many will claim that the ease of use of windows is extremely important. That is simply false, as if one isn't skilled enough to setup a Linux/BSD box, they're going to be one of the people who's boxes get infected with all the "microsoft worms" that spread around...

    --
    Sticking feathers up your butt does not make you a chicken - Tyler Durden
  35. Hardware journaling? by swb · · Score: 2, Troll

    Are there any disk array controllers or other storage devices that do FS-independant journaling at the block level?

    It'd be an interesting way of doing backups -- instead of restoring from tape, you could get the disk controller to back out changes to a specific timestamp.

    I'm sure there are some gotchas -- without knowledge of the filesystem, a specific hardware level transaction may not have complete filesystem level coherency, for one. And it may take a lot of disk to keep a log of any decent duration.

    But it still seems like an interesting way to accomplish some kind of fault tolerance for any OS.

    1. Re:Hardware journaling? by RelliK · · Score: 2

      Uhhm, there is no such thing as "hardware journalling". It's an oxymoron. By definition, journalling is file system-dependent.

      As for restoring changes with specific time stamp, there are three problems with that:

      1. The amount of storage space required would grow exponentially (depending on how fine-grained the timestep is).

      2. The speed would go down the toilet (again, depending on the timestep).

      3. It would still be file system-dependent.

      FYI, the NetApp filers have the "snapshot" feature which allows you to recover deleted files. But note that it works only for deleted files. It does not keep track of modifications. So that's really trivial (something similar to "recycle bin" in windows), and could easily be implemented in any file system. Speaking of which, I'm surprised it hasn't been done yet.

      --
      ___
      If you think big enough, you'll never have to do it.
    2. Re:Hardware journaling? by swb · · Score: 2

      Uhhm, there is no such thing as "hardware journalling". It's an oxymoron. By definition, journalling is file system-dependent.

      Why is that? A simple version of what I'm thinking of would be a disk controller with two disks attached. One is your real disk the other is the journal disk. Every block level operation would be written twice, once to the real disk, and one to the transaction log with a timestamp.

      Clearly any reasonably busy filesystem would require a lot of storage to maintain the transaction log (and maybe that's what would make this impractical for high-volume systems), but how many systems with 100G of disk modify all 100G every day? 100G of disk with 10G of modification per day could be journaled for at least 9 days with an equivilent journal disk.

      Speed is a non-issue, IMHO. Any reasonably modern disk array controller can handle mirrored writes with no problem, and this is not much different from mirroring.

      Many SAN storage systems have the ability to make snapshot copies of individual LUNs, I was told by one vendor that they were working on the ability to make incremental copies of a snapshot.

      Journaling a LUN seems like a logical extension of this ability, and a way to provide fault tolerance.

  36. Problem with Journaling FS by tie_guy_matt · · Score: 3, Funny

    When I first switched to Reiser I had this habit of just turning off the power to my box every few minutes just because I could. No good could come from this. Hopefully as more people switch to journaling FS they will have more self control than I had. Anybody else do the same thing? It is so addictive! Must resist turning off box after I post this...

  37. Re:Woohoo! by mindstrm · · Score: 2

    A JFS doesn't protect your data, it simply allows you to reboot faster after a crash.

  38. Re:more about ext3 by Legion303 · · Score: 2, Funny
    I don't trust FAQs whose authors write like they're on IRC:

    "make sure u download the correct patch."

    -Legion

  39. Well.. by mindstrm · · Score: 5, Insightful

    I don't judge a filesystem based on what kind of tools are there to 'convert' it from something else. That's not what it's designed for, and has nothing to do with what you get out of it.

    No kidding ext2 takes seconds to convert to ext3... it's the same filesystem.

  40. ext3 needed in main tree now by walt-sjc · · Score: 3, Interesting

    I believe Linus has learned to be a little more realistic with releases. While publicly he states that he doesn't care a hoot about what any polls, groups, or the press want or think, and is only interested in building the best dang kernel, my guess is that he desires to see Linux really catch on in the corporate world (and I'm talking linux vs other unix - not displacing MS.)
    The corporate world really wants to see business features in the production kernel such as a rock solid good performing VM, a journaling file system, etc. The older kernels' VM and lack of journalling were really singled out as being critical hurdles for corporate acceptance.

    It didn't matter that RedHat had ext3 or ReiserFS, it was needed in the base kernel without messing around with patches. It's more of a mindset / perception thing than reality.

    The fact is, the corporate world wasn't going to wait another 2 years for 2.6. Those features really needed to be mainstream now. The only thing I'd really like to see added are extended ACLs, but that can wait. I don't know if a solution to device numbering can if Linus won't assign new numbers... (Alan will however, in his tree...)

    Thanks Linus! And a big thanks to all the hundreds of other kernel hackers that made this all possible!

  41. Just Great by Tachys · · Score: 2

    Now Slashdot is posting pre versions of the kernel.

    2.4.15pre2 is out!!!

    1. Re:Just Great by rjamestaylor · · Score: 2, Funny

      Now the Trolls are posting complaints about Slashdot posting pre versions of the kernel.

      --
      -- @rjamestaylor on Ello
  42. Re:Tip: Root partition not being mounted ext3? by Miles · · Score: 2, Informative

    Actually, I've found that putting ext3 (in /etc/fstab) with no ext3 support will automagically mount as ext2. I've also heard that having something like ext3,ext2 will work, but I've never tried it.

    Oh, and to check if you have ext3 you can also use tune2fs -l /dev/blah and look for the has_journal flag in the Filesystem features field.
    For your root filesystem, you may also see something like VFS: Mounted root (ext3 filesystem).

    Andrew.

  43. You don't get the set analogy, do you? by Lethyos · · Score: 2

    You've completely missed my point regarding the set example. If YOU are only using features 0 through N, and not caring one bit about N+x where x > 0, then the addition of those features doesn't affect you. Adding ext3 support is not only minor, it also does not affect you if you choose not to use it. If you don't think ext3 is stable, just don't compile it when you build your next kernel. Simple! You go back to the original set. There's nothing wrong with adding new drivers to stable kernels. It's been done constantly and it's necessary for Linux or ANY operating system to survive.

    --
    Why bother.
  44. minor gotcha with "auto" by David+Jao · · Score: 2, Informative
    If you mount all your filesystems as "auto", and you use slocate, then be sure to edit the small file /etc/updatedb.conf and remove "auto" from the list of PRUNEFS types.

    Otherwise updatedb will ignore your "auto" filesystems (i.e., your whole system) and the slocate database will be empty.

  45. Userbase ... by gotan · · Score: 2

    Well, ext3 is very easy to test out, and it will soon get a large Userbase. More users means it's getting more attention, which in turn means more development. The different journaling filesystems are not too different from each other considering performance (and that's what most people are concerned with), a while ago reiser was the best performer AFAIR, but with more development going into ext3 that might soon change. I think it makes sense to put your bets on the Filesystem where you expect the most development to happen.

    --
    "By the way if anyone here is in advertising or marketing... kill yourself." -- Bill Hicks
    1. Re:Userbase ... by mindstrm · · Score: 2

      Yes. I like the fact that ext3 is an addition to ext2 as well...

      I don't expect that much development into ext3. Why? It has a clearly defined goal: Journalling. Once journalling works, and is optimized... that's it.

      Reiserfs, and others, have many other features as well.

  46. You can't just power off by ChrisWong · · Score: 2, Informative

    Red Hat 7.2's release notes on ext3:

    Please keep in mind that even a journaling file system can be damaged by power loss. When a system loses power, that system's behavior is
    undefined. For example, memory contents can decay (become randomly corrupt) as the contents are copied to a hard drive running on the
    last bit of power. This is a fundamentally different situation from the more defined sequence of events caused by pressing the system's "reset" button while the system is running. In addition, IDE hard drives do not provide all of the write order guarantees that SCSI drives do.

  47. Re:Uh, No. He's Adding Support, Not Replacing ext2 by scrytch · · Score: 2

    In the case of ext3, I actually agree with what is otherwise the greatest example of weasel-wording since the Evangelists excusing everything Apple does.

    ext2 does not synchronously write metadata -- a power fail can hose everything. Thus I consider ext3 a bugfix on ext2, albeit a somewhat radical one. Same goes for the AA VM, a radical bugfix on a broken VM that should have been a show-stopper for 2.4 in the first place.

    Otherwise, you're pretty much the kind of support Linux frankly doesn't need. Keep giving people attitude, soon enough you won't have to anymore, because they'll turn elsewhere.

    --
    I've finally had it: until slashdot gets article moderation, I am not coming back.
  48. Ext3 not safe against power-down by Euphonious+Coward · · Score: 2, Informative
    I see post after post reporting gleefully that people now can just pop off the power, believing that journaling will save their data from harm.

    It's not true.

    If you have only SCSI disks, it may be true, if your disks are from a very reputable manufacturer. (They are few, and charge more.)

    If you have IDE disks, it is almost certainly false. IDE disks report data successfully written to disk when it is still only in on-board RAM buffers. Even when told not to, they often do it anyway. (Lying results in better benchmark scores.)

    If you have IDE disks, journaling will help protect you against various lockups and crashes, but if the disk is active when the power goes out, all bets are off. If you think you didn't lose data, maybe you got lucky, or maybe you just haven't noticed your losses yet.

    The reason IDE disks are cheaper than SCSI is that the people who buy IDE disks have much, much lower quality standards. To compete, the manufacturers are forced to deliver lower quality. If you care about reliability, buy SCSI (or fiber-channel, or ...).

    If you use IDE, watch that power switch, and keep current backups. If you maintain critical data, invest in a UPS. Journaling is not a substitute for a UPS, it's just a time saver.