Each FCL record returned by vxfs_fcl_read
is of variable size and consists of the fcl_record
structure, followed by the additional data associated with the record. The pointers in the fcl_record
structure point to the data stored after the fcl_record structure and the record length specifies the size of the variable sized record. However, making an in-core copy of the FCL record involves more than replicating fr_reclen
bytes of data from the source to the copy.
A simple memory copy just copies over the pointers from the source record to the target record. This leaves the pointers in the target record pointing to data from the source. Eventually, this can cause problems when the memory for the source record is re-used or freed. The pointers in the replica must be modified to point to data in the target record. Therefore, to make an in-core copy of the FCL record, the application must use the vxfs_fcl_copyrec
function to copy and perform the pointer relocation. The user application must allocate the memory needed for the copy.
This sample application is for a system that maintains an index of all files in the file system to enable a fast search similar to the locate
program in Linux. The system needs to update the index periodically, or as required with respect to the file changes since the last index update. The following lists the basic steps to perform and shows a sample call to the FCL API.
fcl_keeptime
and fcl_maxalloc
to the required values.
First run of the index maintenance application
Periodic run to update the index
# vxfs_fcl_read(fh, buf, BUFSZ, FCL_ALL_v4_EVENTS, &nentries)
The following sample application computes the usage profile of a particular file, that is, the users who have accessed a particular file in the last hour.
This sample application needs additional information such as tracking file opens and access information, that are available only with FCL Version 4. Be sure to enable the correct FCL version.
The following steps perform the required initial setup.
# fcladm -o version=4 on mntpt
Note
If this step fails, use fcladm print
to check for an existing FCL Version 3 file. If present, remove it with fcladm rm
and then try switching on FCL with Version 4.
In VxFS 5.0, the default FCL version is 4. If there is no existing FCL file, the fcladm on mntpt
command automatically creates a Version 4 FCL.
fcl_keeptime
, fcl_maxalloc
, and fcl_ointerval
as required. For example:
The following provides sample steps for possible application use.
In some scenarios, a user application may choose to save the bandwidth for the production server and outsource the job of processing the FCL to a different system. For off-host processing, the FCL file needs to be shipped to the off-host system. Since the FCL file is not a regular file, a command such as cp
or ftp
does not work.
To be" shippable," the FCL file must first be dumped into a regular file using the fcladm dump
command. The file can then be sent to the off-host system using normal file transfer programs. See the following example.
# fcladm -s savefile dump mntpt
On the off-host system, the FCL file must be then restored using the restore
option through the fcladm
command. Unlike the original FCL file, the restored file is a regular file.
# fcladm -s savefile restore restorefile
The restored FCL file can be passed as an argument to vxfs_fcl_open
for further use with the FCL API.
Caution The reverse name lookup API does not work on the off-host system. The off-host processing mechanism should only be used when the application can work with the inode number and generation count, or when it has an independent method to determine the file names from the inode number.