| Red Hat Docs > Manuals > Red Hat Linux Manuals > Red Hat Linux 7.2 > |
The kernel now includes the ext3 journalling filesystem. This filesystem has 3 modes of operation:
ordered
journal
writeback
The default is ordered, which will make sure that after a crash you should always see valid data in recently-written files.
The writeback mode can be faster in some cases, but it does not force data to disk so rigorously; therefore, after a crash you may see corruption in recently-written files.
The journal mode copies all data to the journal, and can result in great speed boosts if you are performing lots of synchronous data writes (for example, on mail spools or synchronous NFS servers). However, in normal use journal mode is usually significantly slower.
The mode is set by using the data=<mode> mount option in /etc/fstab or as mount -o data=<mode> on the mount command line.
Normally, an ext2 filesystem is checked automatically once either a certain period of time or a given number of mounts have passed since the filesystem was last checked. At these times, a full fsck (file system check) of the filesystem will be forced at system boot time in order to check the integrity of the filesystem.
When the installer creates an ext3 filesystem or upgrades an ext2 filesystem to ext3, it disables these automatic checks. Use tune2fs with the -c and/or -i options to re-enable them, or to disable them on ext3 filesystems that you create manually.
Note that these cleanup fsck scans have nothing to do with the filesystem's behavior when an error is discovered on disk, or when a crash occurs. If a filesystem consistency error is found on disk, then on subsequent reboot a fsck will always be forced, both for ext2 and ext3 filesystems. If a crash occurs on an otherwise intact filesystem, ext2 will always force a fsck, and ext3 will always perform its filesystem recovery step; these cleanups are not affected by the tune2fs forced-check interval settings.
Please keep in mind that even a journaling file system can be damaged by power loss. When a system loses power, that system's behavior is undefined. For example, memory contents can decay (become randomly corrupt) as the contents are copied to a hard drive running on the last bit of power. This is a fundamentally different situation from the more defined sequence of events caused by pressing the system's "reset" button while the system is running. In addition, IDE hard drives do not provide all of the write order guarantees that SCSI drives do.
Therefore, after a system crash, you will be offered a chance to
choose to check the integrity of your filesystems. The file
/.autofsck is the "crash flag" used to provide
this functionality. You will be given five seconds to type
Red Hat Linux will install a kernel optimized for Athlon processors on systems with an Athlon-class CPU. Due to the optimization, this will put a greater load on the system components. Therefore, a very small number of machines may fail to boot as a result of the hardware not strictly conforming with AMD's specifications and thus being unable to cope with the load. On such systems, you can either upgrade the hardware (under-powered power supply units can cause this) or use the rescue capability of the installer to install an i686 kernel.
Some Athlon-class machines are out-of-spec or have overly aggressive chipset configurations set by their BIOS. On these systems, you may see random "Oops" messages at boot time (after successfully completing the install process) and will be unable to boot successfully. On these systems, boot with the noathlon option to turn off the athlon optimizations; install the 686 kernel instead of the athlon kernel to avoid this for the future.