With the 2.4 release of Linux come a host of new filesystem possibilities, including Reiserfs, XFS, JFS, and others. These filesystems sound cool, but what exactly can they do, what are they good at, and exactly how do you go about safely using them in a production Linux environment? Daniel Robbins answers these questions by showing you how to set up these new advanced filesystems under Linux 2.4. In this installment, Daniel takes a look at ext3, a new improved version of ext2 with journaling capabilities. Make sure you read the also incredibly interesting previous articles: Parts 1, 2, 3, 4, 5 and 6.
Advanced Filesystem Implementor’s Guide, Part 7
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I’m going to go w/ ext3 when the new 5. TB arrives for the server. I like the other fs, but I wish that one was marked as ‘stable’.
I know that ext3 is also marked as unstable. This worries me, but I like the backwards compatability. Also, what’s up w/ the borken loop back dev in 2.4.14? I want to go w/ new vm, but we need to have loop back on a production kernel so I’m at a loss as what to do. Anyone else think I should implement a different fs on the new .5 TB?
Effectively the devfs seems a nice approach since the actual /dev, but I’ve read something nicer about the qnx resource manager, allowing any process to reserve any pathname in the filesystem tree and managing it, while other processes talk to it through standard i/o functions (open, read, write..).
Here the devfs has no meaning because the os itself let process registering their block/char capabilities into the tree.
The example of qnx documentation shows a program which could drives a robot’s arm through a registered path like /dev/robot/, and manage sub path like arm/angle/ which can then be used with standard utilies like : “echo 87 >/dev/robot/arm/angle” (or something like) to turn the arm by 87 degrees.
Nicer.