with the state of the operating system.
Three modes available as options to ext3 are as follows:
> writeback — Enables old data to stay in the file system, attaining the fastest speed possible. It does not schedule any data writes; it just enables the kernel's 30-second writeback code to flush the buffer.
> ordered — Keeps the data consistent, but with some sacrifice in speed (the default mode for Fedora).
> journal — Requires more disk space to journal more data. You might see slower performance because data is written twice, but there are some speed benefits if you are doing synchronous data writes, as in database operations.
For most of us, the default selection represents a good trade-off. Fedora supports booting from an ext3 formatted root file system with the proper drivers loaded in the initrd image.
You select the mode by using the appropriate mount option in /etc/fstab. For example, to set the file system mode to the fastest of the three modes, use data=writeback as the option. For more details, enter man mount.
Verifying File Integrity in ext3 File Systems with the fsck Utility
You assure file system integrity by using the fsck, or file system check, program — one of five commands in the library that are used to maintain and modify the ext3 file system.
When fsck is run, it performs a sequential analysis of the file system information available in the file system if it detects a directory that cannot be traced back to the root or an undeleted file with a zero link count. It places these directories and files in the /lost+found directory that is created on each physical partition by the file system formatting process. Some blocks are reserved for this and other uses of the super-user. It is possible to reduce this allocation to free additional space for regular users by providing special arguments to the formatting program mke2fs.
To run the fsck command, use the name of the file system as the argument. You must ensure that the file system you want to check is unmounted by using the umount command. If you want to fsck the file system at /dev/hdc, for example, do this:
# fsck /dev/hdc
If you are logged on as a regular user and su to root using su, you do not inherit root's environment and path, meaning that the preceding command does not work unless you use the full path: /usr/sbin/fsck.
Either type the full path each time, or become root with su -, which causes you to inherit root's environment and path; you have less to type.
The file system state is tracked in the ext3 file systems. A special field in the superblock tells the kernel that, after the file system is mounted read/write, it is marked as not clean; when it is properly unmounted, it is marked as clean. If a file system is not unmounted properly, it could contain corrupt data because all the file data might not have been written to it. (This is what the journaling file systems such as ext3 strive to eliminate.) When the system is booted, this flag is checked and if it is not clean, the program fsck is run. Internally, fsck is actually a wrapper program that runs the appropriate version of fsck for the file system in use: fsck.minix, fsck.ext2, fsck.ext3, fsck.reiserfs, fsck.msdos, or fsck.vfat. If the kernel detects an inconsistency in the superblock field, the file system is marked erroneous, and the file system check is forced even if other indicators suggest that fsck does not need to be run.
By default, the system runs fsck on a file system after a periodic number of reboots, regardless of the status of the clean flag. This behavior is triggered by a mount counter kept in the superblock or after a predetermined amount of time has elapsed since the last reboot (information also kept in the superblock). These parameters can be adjusted through the tune2fs command; this command can also be used to modify how the kernel handles the erroneous flag and, interestingly, the number of blocks reserved for the super-user, also known as root. This latter option is useful on very large or very small disks to make more disk space available to the user.
Other File Systems Available to Fedora
Although ext3 is certainly an acceptable root file system, there are other alternatives. No operating systems can support as many root file systems as Linux, but you should be aware that every file system has its strengths and weaknesses. Some are better with small files, some are better with large files; some are better at writing data, and some better at reading data. Unfortunately, there is no one perfect file system. The following sections discuss some of the other common file systems available for use with Fedora.
The Reiser File System (reiserfs)
The other popular journaling file system for Linux is the written-from-scratch Reiser file system, reiserfs. For a long time it was used by the SUSE distribution, but SUSE now uses ext3. reiserfs offers similar features to ext3, but there is no easy migration path from an already existing ext2 partition. In the past, reiserfs didn't work well over NFS mounts, but recent versions of the nfsd daemon have fixed those problems. Fedora does offer reiserfs, but does not offer support for booting from it as the root partition file system, nor does it offer the choice to format non-root partitions as reiserfs during the installation process.
reiserfs is offered primarily for compatibility with existing reiserfs partitions you might want to access. Although the Reiser file system can be used as a root file system (meaning that Linux can be booted from a Reiser file system), Fedora has chosen not to support that option. The main problem is that reiserfs does not, at the time of writing, play nicely with SELinux and is therefore not recommended either by Red Hat or the NSA (SELinux's developers).
Namesys, the company behind reiserfs, has struggled since its founder (Hans Reiser) was arrested as part of the police investigation into the murder of his wife. Few distros now recommend using reiserfs, so we would recommend avoiding it for the foreseeable future.
JFS and XFS File Systems
