Slashdot Mirror

← Back to Stories (view on slashdot.org)

Ext3 Filesystem Explained

Posted by michael on from the journaling-for-fun-and-profit dept.

sheckard writes: "The next installment of the wonderful Advanced filesystem implementor's guide, part 7, details the ext3 filesystem in all of its glory. This is another great voyage into the world of journaling filesystems, and ext3 has been rock-solid in my experience."

5 of 174 comments (clear)

  1. Distro battles? Nah. Journaling fs battles! by Deal-a-Neil · · Score: 5, Informative

    ext3 catches my fancy because there's no ext2 --> ext3 conversion -- you just have to unmount, make a journal file, and remount. reiserfs migration is a challenge for the huge partitions.

  2. Excellent engineering by ppetru · · Score: 5, Insightful

    The very existence of ext3, and it's complete forward and backward compatibility with ext2, shows that ext2 was extremely well designed by it's authors. Kudos to Remy Card, Ted Tso, and the rest of the ext2 team!

    Also, based on the same extensibility of ext2, Daniel Phillips is working on a directory indexing patch which speeds up ext2 by a huge factor when working with lots of files in a directory. You can get the preliminary patches here and see a graph of a simple file creation benchmark here. Amazing!

    --

    Petru
  3. Re:Partition resizing? by Sapien__ · · Score: 5, Informative
    This thread might be useful.

    To summarize: yes, it's possible to resize ext3 partitions, so long as your resizer doesn't mind. Don't use Partition Magic to do it. It doesn't like it. Badly.

  4. Re:The journalling filesystem myth by cowbutt · · Score: 5, Informative
    Let's say the journaling file system has 5% overhead (it probably has more). That means you lose more than 1h per day on a busy server--it's spread out, but it's still lost. You'd have to do a lot of rebooting in order to make up for that in terms of "saved" fsck time.

    Actually, Andrew Morton reckons ext3 is actually quicker than ext2 in spite of the journalling. Go figure. :)

    --

  5. Re:The journalling filesystem myth by edhall · · Score: 5, Insightful

    A few points:

    1. You can't equate down-time to a slightly slower response time. Having a reboot time of tens of seconds vs. tens of minutes for (e.g.) a large source repository or a critical web server is well worth a minor performance hit. Reboot time is dead time for all who need access to the server.
    2. If your file server is running so close to capacity that a 5% decrease in maximum filesystem throughput represents a 5% slowdown in actual throughput, your server is dangerously overloaded already.
    3. In general, journaling affects write performance, not read performance. If your server performs mostly reads, the overall overhead of journaling may amount to much less than your 5% figure. Most (though not all) applications for file servers are read-intensive with incidental writes apart from the initial "load" of the server.
    4. Fast fsck's aren't the main reason for journaled filesystems. Rather, its the improvement in filesystem integrity that is the main attraction -- an improvement that incidently allows for fast fsck's.
    -Ed