Administering filesystems

VxFS advanced mount options

The Filesystem Manager supports the following mount options for VxFS filesystems:

Mode of Intent Logging
By default, VxFS filesystems log file transactions before they are committed to disk, reducing time spent checking and repairing filesystems after the system is halted unexpectedly. You can configure this behavior as follows:

Clear Blocks Before Allocating File?
clear data extents before being reallocating to another file. This ensures that existing data is always overwritten with zeroes before the disk space is released.

See also:

Understanding sync-on-close

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:

Unmount and remount the filesystem to make the change take effect. If you have modified the root filesystem, you must reboot the system.

WARNING: The sync-on-close option only applies to VxFS filesystems.

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.

Understanding intent logging

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.

NOTE: Intent logging does not increase the reliability of filesystem. Only transactions concerning file meta data (the structures concerned with storing data) are logged. The purpose is to minimize system downtime. For optimum benefit, intent logging should be enabled.

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:

Next topic: Filesystem mount options (HTFS, EAFS, AFS, S51K)
Previous topic: Enabling users to mount filesystems

© 2007 The SCO Group, Inc. All rights reserved.
SCO OpenServer Release 6.0.0 -- 05 June 2007