First of all, there is no a clear winner, XFS is better in some aspects or cases, ReiserFS in others, and both are better than Ext2 in the sense that they are comparable in performance (again, sometimes faster, sometimes slightly slower) but they a journaling file systems, and you already know what are their advantages... And perhaps the most important moral, is that Linux buffer/cache is really impressive and affected, positively, all the figures of my compilations, copies and random reads and writes. So, I would say, buy memory and go journaled ASAP...

Keywords: Linux, operating systems, page cache, buffer cache, journal file systems, ext3, xfs, reiserfs, jfs.

Introduction

The paragraph above was the first one in an article published in the Balearic Islands Linux User Group web which described a second run of benchmarks over the Linux journaled file systems in comparison against traditional Unix file systems.

Although somehow informal, both benchmarks covered FAT32, Ext2, ReiserFS, XFS, and JFS for several cases: Hans Reiser's Mongo benchmark tool, file copying, kernel compilation and a small C program that to simulated the access patterns of database systems.

Both articles were among the first published, and our server was overwhelmed due the slashdot effect derived from their publication in slashdot.org. They mainly served to de-mystify the common believe that journaling file systems are significantly slower in comparison with traditional Unix file systems (UFS) and derived, namely ext2, which has been the standard file system in Linux.

Since those days, more benchmarks have been published, but the truth is still the same: there is not a clear winner. Some systems perform better than other in some cases, for example ReiserFS is really good for reading small to medium size files, while XFS behaves better for large files, and JFS is said to facilitate the migration of existing system running in OS/2 Warp and AIX systems.

This article presents the all journal file systems available for Linux: Ext3, ReiserFS, XFS and JFS. We also introduce the basic concepts of file systems, buffer-cache, and page-cache implemented in the Linux kernel. The performance of the different file systems is strongly affected by those optmisation techniques. Indeed, not only the performance is affected, but also the implementation and porting of the different file systems. SGI introduced a new module, pagebuf, that serves as the interface between their own XFS buffering techniques and the Linux page cache.

The Linux Virtual File System

A File is a very important abstraction in the computing programming field. Files serve for storing data permanently, they offer a few simple but powerful primitives to the programmers. Files are normally organised in a tree-like hierarchy where intermediate nodes are directories, which in turns are capable of grouping files and sub-directories.

The file system is the way the operating system organises, manages and maintains the file hierarchy into mass-storage devices, normally hard disks. Every modern operating system supports several different, disparate, file systems. In order to maintain the operating system modular, and to provide applications with a uniform programming interface (API), a higher layer that implements the common functionality of those underlying file systems is implemented in the kernel: the Virtual File System.

File systems supported by the Linux VFS fall into three categories:

1. Disk based, including hard disk, floppy disk and CD-ROM, including ext2fs, ReiserFS, XFS, ext3fs, UFS, iso9660, etc.
2. Network based, including NFS, Coda, and SMB.
3. Special file systems, including /proc, ramfs, and devfs.

The common file model can be viewed as object-oriented, with objects being software constructs (data structures and associated methods/functions) of the following types:

• Super block: stores information related to a mounted file system. It is represented by a file system control block stored on disk (for disk based file systems).
• i-node: stores information relating to a single file. It corresponds to a file system control block stored on disk. Each i-node holds the meta-information of the file: owner, group, creation time, access-time and a set of pointer to the disk block that store the file date.
• File: stores information relating to the interaction of an open file and a process. This object only exists while a process is interacting with a file.
• Dentry: links a directory entry (pathname) with its corresponding file. Recently used dentry objects are held in a dentry cache to speed up the translation from a pathname to the inode of the corresponding file.

All modern Unix systems allow file system data to be accessed using two mechanisms (Figure two).

1. Memory mapping with mmap: The mmap() system call gives the application direct memory-mapped access to the kernel's page cache data. The purpose of mmap is to map a file data into a VMS address space, so data in the file can be treated as a standard in-memory array or structure. File data is read into the page cache lazily as processes attempt to access the mappings created with mmap() and generate page faults.
2. Direct block I/O system call such as read and write: The read() system call reads data from block devices into the kernel cache (avoided for CD and DVD reading by means of O_DIRECT ioctl parameter), then it copies data from the kernel's cached copy onto the application address space. The write() system call copies data in the opposite direction, from the application address space into the kernel cache and eventually, in a near future, writing the data from the cache to disk. These interfaces are implemented using either the buffer cache or the page cache to store the data in the kernel.