|
|
The Filesystem Manager supports the following mount options for VxFS filesystems:
See also:
Normally, file data is written ``asynchronously'', meaning that when a file is closed, the data may not be written to the disk immediately. If the system is halted unexpectedly. this data can be lost. When ``sync-on-close'' is enabled, data is always written to disk immediately when a file is closed. This feature significantly affects system performance because of the additional time spent writing to the disk. Disabling sync-on-close can increase throughput at the expense of data integrity.
Sync-on-close is enabled by default. To disable it, edit the /etc/default/filesys file with a text editor. Each line in this file corresponds to a filesystem and consists of several tab-separated fields. The sixth field contains the mount options. Remove the following entry, taking care not to remove other options or fields:
mincache=closesyncUnmount and remount the filesystem to make the change take effect. If you have modified the root filesystem, you must reboot the system.
Some caching disk controllers use write-back caching techniques that nullify the improved data reliability and integrity provided by VxFS. If this is the case, data integrity cannot be guaranteed. However, controllers that use write-through caching take advantage of VxFS features. If your controller supports both caching techniques, configure it to use write-through caching. See UNRESOLVED XREF-0 for more information.
Intent logging minimizes system downtime after abnormal shutdowns by logging filesystem transactions. When the system is halted unexpectedly, this log can be replayed and outstanding transactions completed. The check and repair time for filesystems can be reduced to a few seconds, regardless of the filesystem size.
The ability to locate and check only affected areas of the disk for inconsistencies is central to the logging mechanism. The structure of the mechanism is described in detail in ``Fast filesystem recovery for VxFS''.
If the system crashes before the log is written, it is as if the change (any modifications to the filesystem) never occurred. If the system crashes after the log is written, but before the transaction complete, fsck either completes the change or undoes it. If the system crashes after the transaction is completed, then the modification has been completed, and there is nothing for fsck to do.
See also: