DOC HOME SITE MAP MAN PAGES GNU INFO SEARCH PRINT BOOK
 
Administering filesystems

Filesystem mount options (HTFS, EAFS, AFS, S51K)

The Filesystem Manager supports the following mount options for non-root HTFS, EAFS, AFS, and S51K filesystems; for root filesystems, see ``Modifying HTFS, EAFS, AFS, and S51K root filesystem mount configuration''.


Mount as Temporary Filesystem
mounts the filesystem as a temporary data area (such as /tmp). This improves system performance because the system updates the information less frequently. (The potential for loss of data is increased as a result.)

Checkpointing
transitions the filesystem to a clean (consistent) state at regular intervals. This reduces the probability that your filesystem will need cleaning if the system is halted unexpectedly.

Logging
performs ``intent logging'', recording filesystem transactions to a log file before they are committed to disk. This increases data availability by reducing the checking and repairing the filesystem to a few seconds. This time is independent of filesystem size.

These options apply to HTFS filesystems only:

Maximum number of file versions
determines maximum number of undeletable (versioned) files allowed on the filesystem. A value of 0 disables versioning.

Minimum time before a file is versioned
sets minimum time before a file is versioned. If set to 0, a file is always versioned (as long as Maxiumum number of file versions is greater than 0). If set to a value greater than 0, the file is versioned after it has existed for that number of seconds.

See also:

Mounting as a temporary filesystem

To improve performance, your temporary filesystem (for example /tmp, /u/tmp, or /usr/tmp), can be set up as either an EAFS, AFS, S51K or HTFS filesystem type. If you have any temporary filesystems, you can select this option so they are mounted as temporary filesystems automatically every time the system is rebooted.

Temporary filesystems are updated less frequently and are recommended for use on filesystems containing temporary data only. If this option is used on /tmp, the overall system performance may improve.


CAUTION: Some applications use /tmp to save data. If this option is enabled, then the ``checkpointing'' feature will be disabled automatically.

Checkpointing your filesystem

Checkpointing is the process of transitioning filesystems to a clean (consistent) state. Filesystem data consists of user file data (the contents of a file) and the data structures used to store the data (also known as ``meta data''). Recently-accessed data is held in memory (``cached'') for a short time in case it is needed again. If the system is stopped unexpectedly, this cached data can be lost.

By default, HTFS, EAFS, AFS, and S51K filesystems periodically ``checkpoint'' (write) cached meta data back to disk. This increases the probability that the filesystem meta data will be in a consistent state if the system is halted unexpectedly. (There may be a small loss of user data, which is not checkpointed.)

If your system should experience a system error, checkpointing will reduce the likelihood that the filesystem will need to be checked and repaired with fsck(ADM) when rebooting, thus mimimizing downtime.


NOTE: While checkpointing is appropriate for most users of HTFS, there is a small performance penalty. To achieve maximum throughput, you should consider disabling checkpointing.

See also:

Logging filesystem transactions

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.

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:

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.


NOTE: For optimum benefit, both logging and checkpointing should be enabled. Checkpointing marks the filesystem as clean whenever the filesystem is inactive. If the system needs to be checked (in the event of an abnormal system halt, for instance) only areas of the disk manipulated since the last checkpoint operation need to be examined for inconsistencies.

See also:

Versioning filesystems (undelete)

Versioning allows deleted files to be recovered with the undelete(C) command or on the Desktop as described in ``Deleting and recovering files and directories''. If versioning is enabled on a filesystem, files and directories can be designated for versioning and administered as described in ``Retrieving deleted files''. The versioning feature can be enabled system-wide or for individual filesystems.

To enable versioning on all non-root DTFS/HTFS filesystems:

  1. Use the Hardware/Kernel Manager as described in ``Configuration tools''. Select category 10, ``Filesystem configuration.''

  2. Relink the kernel with the new filesystem parameters -- see ``Relinking the kernel''.

  3. Reboot the system by entering:

    reboot

To enable versioning on a per-filesystem basis, see ``Filesystem mount options (HTFS, EAFS, AFS, S51K)'' and ``Filesystem mount options (DTFS)''.

To enable versioning on the root filesystem, see ``Modifying HTFS, EAFS, AFS, and S51K root filesystem mount configuration'' or ``Modifying HTFS, EAFS, AFS, and S51K root filesystem mount configuration''.


Next topic: Filesystem mount options (DTFS)
Previous topic: Enabling users to mount filesystems

© 2003 Caldera International, Inc. All rights reserved.
SCO OpenServer Release 5.0.7 -- 11 February 2003