Managing RAID on Linux - Derek Vadala [113]
# mke2fs -O journal_dev /dev/md0
Now /dev/md0 is a journal device usable by an ext3 filesystem. When a journal device is created, all the space available on the device is allocated for the journal, so it's important to repartition your disks appropriately. Using a pair of 9 GB disks for a journal device is overkill and will impact performance, especially when the system boots. Create smaller partitions and add them to your array. Next, create an ext3 filesystem that uses your journal device to store transaction logs. For instance, the following creates /dev/md1 and allocates the preexisting /dev/md0 as its journal device:
# mke2fs -J device=/dev/md0 /dev/md1
Further Information
For more detailed information about ext3, refer to the ext3 home page (http://www.zipworld.com.au/~akpm/linux/ext3/) as a starting point. The ext3 mailing list is also of particular interest:
https://listman.redhat.com/mailman/listinfo/ext3-users/
Finally, the following paper describing some of ext3's features:
http://www.redhat.com/support/wpapers/redhat/ext3/index.html
ReiserFS
ReiserFS is the brainchild of Hans Reiser, although today, a large cavalcade of developers is involved in its production. ReiserFS was the first journaling filesystem developed for Linux and has held its own remarkably well, considering that IBM and SGI have contributed impressive alternatives (the JFS and XFS filesystems, respectively).
Reiser began the ReiserFS project with an untraditional design that uses balanced trees[5] to manage and organize the filesystem, instead of a traditional linked list approach. Balanced trees have been used for quite some time in database architecture, but various disappointing attempts to create balanced-tree filesystems have led many in the operating system community to believe they are not suited to that purpose. Reiser, on the other hand, maintains that a proper implementation will eventually result in a better-performing and more reliable filesystem. While some other filesystems that have implemented the balanced tree algorithm used the tree to manage only metadata, ReiserFS stores both files and filesystem metadata in the balanced tree structure.
The ReiserFS design approach works very well for small files and for filesystem metaoperations, such as deletion. While ReiserFS used to struggle with performance on larger files, those issues have now been all but resolved, and some improved code for large files will appear in the 2.4.20 kernel, as well as in future development kernels. Performance continues to be a priority for Hans Reiser, and it's one of the main goals of ReiserFS version 4. Reiser writes:
Most filesystems are able to run at close to disk bandwidth for large files unless data journaling is in use, and large files without data journaling on are not a good discriminator among filesystems anymore. Reiser4 will be unique in being able to run at close to disk bandwidth with data journaling on, and it will be able to run at close to disk bandwidth with medium and small files written in large batches. In version 3 we turn off data journaling by default, because for large files the performance is horrible due to needing to write the data twice. Wandering logs in V4 cure that, and data journaling will be the default. V4 is in alpha testing now.
ReiserFS originally provided metadata journaling only. In other words, the filesystem remembered after a crash that you wanted to move or delete a file, but did not remember how a file's contents might have changed. When kernel 2.4.20 is released, ReiserFS will support data journaling as well. Previously, users had to apply a patch, written by Chris Mason of SuSE, if they wanted data journaling under ReiserFS.
ReiserFS also implements a file packing approach called file tails. File tails allow unused portions of a filesystem block to be reused to store other files. That means that almost no disk space is ever wasted, making storage