Veritas™ File System 5.0.1 Programmer's Reference Guide

Specifies the time in seconds that must elapse before the FCL records
multiple overwrite, extending write, or truncation records for the
same inode. This helps to reduce the number of repetitive records in
the FCL. The fcl_winterval time-out is per inode. If an inode
happens to go out of cache and returns, its write interval is reset. As
a result, there could be more than one write record for that file in the
same write interval. The default value is 3600 seconds.
Tuning recommendation: The fcl_winterval tunable parameter
should be set to a value that is less than the time between FCL scans.
For example, if the FCL is scanned every 24 hours, fcl_winterval
should be set to less than 24 hours. This ensures that there is at least
one record in the FCL for each file being overwritten, extended, or
truncated between scans.
fcl_winterval
Specifies the time interval in seconds within which subsequent opens
of a file do not produce an additional FCL record. This helps to reduce
the number of repetitive file-open records logged in the FCL, especially
in the case of frequent accesses through NFS. If the tracking of access
information is also enabled, a subsequent file open event within
fcl_ointerval might produce a record, if the latter open is by a
different user. Similar to fcl_ointerval, if an inode goes out of
cache and returns, or if there is an FCL sync, there might be more than
one file open record within the same open interval. The default value
is 600 seconds.
Tuning recommendations: If the application using file-open records
only needs to know if a file has been accessed by any user from the
last time it scanned the FCL, fcl_ointerval can be set to a time
period in the range of the time between the scans. If the application
is interested in tracking every access, the tunable can be set to zero.
In the case where the file system is extensively accessed over NFS,
depending on the platform and the NFS implementation, there might
be a large number of file open records logged. In such cases, it is
recommended to set the tunable to a higher value to avoid flooding
the FCL with repetitive records.
fcl_ointerval
How tunables handle File Change Log growth size
Figure 2-2 illustrates an example of record purging as an FCL file grows in size.
The FCL file on the left contains 8K blocks and no holes. When activity occurs on
the file system, it is recorded in the FCL and the growth results in the FCL file on
the right.
When the FCL file size reaches the maximum allowable size that is specified by
the fcl_maxalloc tunable, older records are purged and space is freed. The FCL
File Change Log
File Change Log tunables
26