Valid XHTML 1.0!


(new since 16. Aug 2001)

General Remarks about File Systems

After owning "only" a classical Inode based UNIX file system (ext2) for years, in the last time rather quickly modern alternatives, based on journaling features, have emerged for LINUX. Of these currently four (!), of course all free, are in different stages of development: one made it with release 2.4.1 already into the official LINUX Kernel (spring 2001), namely ReiserFS, developed by mainly one person (name!) and supported primarily by the SuSE LINUX distribution; two are labeled as stable releases: SGIs fine IRIX descending XFS, which was released at begin of May 2001 and is also under the GPL since going LINUX, as IBMs SQL RDBMS proven JFS, which descends from the AIX and OS/2 systems, JFS was released at end of June 2001. Still under basic development finally is ext3, similar to ReiserFS a pure LINUX community project, and supported mainly by the RedHat LINUX distribution.

Since filesystems are such a tremendous important part of an operating system, I treat now these systems in some detail, to give you hints, which of these can be applied under what circumstances adequately. Partly own experience, partly using test results of different sources, it should be useful for you... The order is due to the time elapsed, since the filesystem was released (if at all). Concluding remark: be aware of the importance of the lvm (logical volume manager), which is tightly bound to the Kernel (version) and to the file system used, so you need for its advantage to change file system sizes and compositions (adding of more hard disks for example) without reformatting a very precisely fitting version of it too, otherwise you may be even unable to mount it!


The classical LINUX (second extended) file system comes with the familiar fsck tool, which is invoked usually all 20 mount actions forced and otherwise only in short. As with any UNIX, for example the leading SUN Solaris ufs (which is regretfully not fully available as well working read/write system for LINUX) Inode filesystem it is able to check and if necessary, when any unclean circumstances like power failures occurred, but then well to repair the filesystem. But the major problem with this technique is, that fsck first needs considerable amounts of time to perform a forced check on large partitions, which are nowadays widespread, and in bad cases it requires root to confirm repair steps manually: this prolongs downtimes after power failures and requires in these worst cases manual interaction, which is bad news for high-productivity systems. Once up after the fsck pass, it's pretty fast and reliable, and you can boot with any manager and in any way you like with it. For a small root partition with hardly changing data it's still a good bet, but store your data in huge amounts better on one of the following filesystems! But for formatting (and checking) a new disk/partition it's often better to try despite of the longer time a first format with verify with ext2, because it writes then Inode informations in a regular manner over the entire chosen partition --- opposed to the journaled ones, which use on creation only a small part and give mostly no clues, if the medium is physically correct at all --- and you can control the logs, whether the disk/partition is physically okay. No other fundamental restrictions apply on ext2 regarding NFS, disk quotas, hardware platforms (CPUs) and so on.

Final remark: about 10% of the disk space are consumed for the Inodes and you should keep the (available without the already occupied Inodes) filling percentage on an ext2 filesystem at a maximum of about 90%, because like any classical UNIX Inode fsck system (as the mentioned Solaris UFS) it begins to display considerable fragmentation, if you exceed these 90% on the file system, which causes a slowdown of operation.


Hans Reiser created a stunning high-performance B-Tree based journaling file system, which proved it's suitability for practical use already clearly. Under usual circumstances it's very stable and reliable, and in some respects even faster then an already running ext2. You have to format a partition new with ReiserFS, because it's 100% incompatible with ext2. At the moment of writing it's the only alternative to the native ext2 filesystem in the current Kernels officially (since 2.4.1 as mentioned), and since Kernel release 2.4.3 the extremely important disk quotas (for file servers and similar systems) work too on it. With SuSE distributions it was already usable without Kernel (re-)build since a long time and has performed well and reliably since then --- even with Kernels around 2.2.10 it worked already. Building or using it, for disk quota support you need at least the version 3.5.33 (watch the message at activation or check the boot.msg/messages files in /var/log) for it. Since NFS is one of the very few remaining weaknesses of LINUX, becaues either you use the user space NFS without locking ability, or the not very stable Kernel NFS daemon, you can face additional problems, when sharing filesystems running ReiserFS with NFS, but as mentioned, it is better to rely on in this regard still clearly superior UNIX systems like SUNs SPARC Solaris (be aware, that the Intel Solaris is not performing well, even worse than LINUX!). For small partitions this file system is less suitable, because it consumes for it's journal system a considerable, constant (partition-size independent) amount of disk space. And that it runs at the time of writing so far I know only on Intel x86 (and AMD of course) architectures, is only a small loss, because LINUX is quantitatively nearly only running on these --- at most the Motorola PowerPC CPUs could give another considerable number of installations for it (meanwhile it seems to be available for Alpha and SPARC too).

Finally, in ReiserFS some additional tools of journaling filesystems are still experimental and not very reliable, but because journaling systems are transaction oriented (similar as RDBMS systems, as SQL systems of Oracle or IBMs DB2), you need them virtually never (exceptions see below)! Altogether Hans Reisers development can be recommended wholeheartedly.


Silicon Graphics Industries (SGI) has a long experience with their eXtended File System on the MIPS/IRIX UNIX platform. Originally technically based on the same roots as JFS of IBM (see below), they developed it for years on their high performance IRIX/MIPS platforms, and you lack nothing, what you can expect from a modern journaling file system as well on LINUX, as on IRIX. The experience with XFS is on the LINUX(/Intel) platform still not very long (see above!) since May 2001, but it has a fine record on IRIX/MIPS, and because SGI offers all features for LINUX too, you can make the most of it. At mid-2001 it is still inferior in most performance measurements, partly considerable to ReiserFS and lvm support is still in its infancy, but possible, probably due to the change from the mips/RISC platform to the dated Intel/CISC architecture, which was better solved by the Intel-inbuild ReiserFS, it can for example delete large files faster than ReiserFS, has full working dump tools (you can build a hot standby system with this, dumping transactions and adding to another XFS, for example!) and since it's 1.0 release (there was a minor update to 1.0.1 since then) already full disk quota and NFS support. Another advantage to ReiserFS is, that the journal systems needs less space, what makes it suitable for less sized file systems than ReiserFS. But be aware, that you may have trouble, to boot from a XFS partition with most common boot managers like LILO for now! However, it's a true 64 bit file system with no notable size limitations, aside from LINUX Kernel imposed limits. Another recommendable file system, that's for sure, despite you have to patch it in midth-2001 manually as source into the Kernel and recompile the Kernel (since 2.4.4). But it's even possible to build a well working Kernel with ReiserFS and XFS support, but partitions with XFS have to be reformatted, either if running ext2 or ReiserFS before.


The International Business Machines (IBM) created very early a UNIX based Journaled File System (the lack of fantasy seems to be a signature of "Big Blue") mainly for their own AIX UNIX implementation, which gained big awards for example by Oracle, the leading SQL RDBMS vendor, for being so stable, reliable and performant regarding transactions, that unlike on other UNIX systems, Oracle recommends using JFS partitions instead of the usual self-administered (by the RDBMS) raw devices (which are luckily also supported by LINUX since Kernel 2.4). You can patch the Kernel versions since 2.2.10 and 2.4.0 with it and have to recompile and in case of usage to reformat the partitions for application of JFS as mentioned with the first two. Full SMP (mainly server oriented) support is included too. Similar to, but even more than with XFS, the record is still mainly AIX based, and so it can't be judged, how well JFS works in longer use at now. The own lvm is great and as SGIs XFS JFS too has no inherent size limits due to its 64 bit nature. By the way, it's reported, that JFS and XFS can be used together on the same machine with a few special patches. But JFS runs at now only on the ix86 systems, strangely not (yet) on PowerPC, where the AIX is running. Watch JFS, but use it with care, I propose...


This one is the only remaining now, which is still experimental. I mention it only, because it offers you the only non-reformatting path of partitions from ext2 to journaling, but this comes at the cost of relatively poor performance compared to the three released and above presented systems. This is definitely not suitable for productivity usage yet, but if you're brave and/or supportive, you may run it experimental on non-vital partitions already. But sure RedHat will try hard to deploy it in an acceptable manner and time, so just wait a little time?

Summary (Subject to Change)

The strengths and weaknesses were already discussed largely above. Some examples follow, to show you, which one to use when:

ext2 is still okay, if you have a not too-big file system (at most 200 MB in size, on slow disks preferably even smaller) which changes not too often and/or is to boot from;
reiserfs is for big data partitions the choice, especially if you have not to NFS mount it to other machines, you get a reliable high performance file system this way on the clearly dominant ix86 architecture only so far (by the way, shame on RedHat for not offering it despite its official Kernel status on their distribution yet, they clearly offend the rules!);
XFS is also for less sized partitions and enables you to "play" around with tools, which make hot standby (physically unrelated other machine running XFS file system(s)) suitable, also NFS and user disk quotas work as good, as LINUX supports it now and finally there seem to be no notable platform/CPU limitations: you can use it not only on ix86, but also on PowerPC (!), Alpha and SPARC machines, despite it's there on the other RISC systems than mips/IRIX of course not as thorougly tested as on the dated Intel/AMD CISC architecture, you have no notable size limits;
JFS offers the SQL RDBMS level reliability, hopefully meanwhile on LINUX too, so you can use it probably already especially for file server applications like IBMs AIX platform, while performance on Intel is still inferior to ReiserFS, but you have the logical volume manager of JFS too (important: own version!), which enables you to change file system sizes on JFS during general user accesses on the JFS partition, also no notable file size limits are present, but as ReiserFS it runs on ix86, Alpha and SPARC ;
ext3 is only suitable for experimental purposes at now, but if you want to migrate file systems without reformatting, it may be your best choice despite the poorest performance of all these LINUX file systems, at least in the medium future.


back to main  back to computer/LINUX main  back to main

remarks etc. to: