Symantec logo

Copying FCL records

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.

Index maintenance application

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.


Preparation

 To prepare the application

  1. Enable the FCL.

    # fcladm on mntpt

  2. Tune fcl_keeptime and fcl_maxalloc to the required values.

    # vxtunefs -o fcl_keeptime=value

    # vxtunefs -o fcl_maxalloc=value


First run of the index maintenance application

 To test est the application

  1. Open the FCL file.

    # vxfs_fcl_open(mntpt, 0, &fh);

  2. Seek to the end.

    # vxfs_fcl_seek(fh, NULL, FCL_SEEK_END);

  3. Get the cookie and store it in a file.

    # vxfs_fcl_getcookie(fh, &cookie)

    write(fd, cookie, sizeof(struct fcl_cookie));

  4. Create the index.
  5. Close the FCL file.

    # vxfs_fcl_close(fh);


Periodic run to update the index

 To update the application

  1. Open the FCL file.

    # vxfs_fcl_open(mntpt, 0, &fh);

  2. Read the cookie and seek to the cookie.

    # read(fd, &cookie, sizeof(struct fcl_cookie))

    # vxfs_fcl_seek(fh, cookie, FCL_SEEK_COOKIE)

  3. Read the FCL file and update the index accordingly.

    # vxfs_fcl_read(fh, buf, BUFSZ, FCL_ALL_v4_EVENTS, &nentries)

  4. Get the cookie and store it back in the file.

    # vxfs_fcl_getcookie(fh, &cookie)

    # write(fd, cookie, sizeof(struct fcl_cookie));

  5. Close the FCL file.

    # vxfs_fcl_close(fh);

Computing a usage profile

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.


Initial setup

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.

 To setup up the application

  1. Switch on the FCL with Version 4.

    # 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.


  2. Enable tracking of access information, file-opens, and I/O statistics as needed.

    # fcladm set fileopen,accessinfo mntpt

  3. Set tunables fcl_keeptime, fcl_maxalloc, and fcl_ointerval as required. For example:

    # vxtunefs fcl_ointerval=value

  4. Close the FCL file.

    # vxfs_fcl_close(fh);


Sample steps

The following provides sample steps for possible application use.

  1. Open the FCL file.

    vxfs_fcl_open(mntpt, 0, &fh);

  2. Set up the time to perform the seek.
    1. Get current time using gettimeofday.
    2. Fabricate the fcl_time_t for the time an hour before.
    3. Seek to the record in the FCL file at that time.

      gettimeofday(&tm, NULL);

      tm.sec -= 3600

      vxfs_fcl_seektime(fh, tm);

  3. Read the file with appropriate event masks until the end of file (The application is interested in only the file open records and the access information).
    1. Check if the file inode number and generation count are same as the ones being sought for each FCL record.
    2. Print information about the user who has accessed the file, if applicable.

      vxfs_fcl_read(fh, buf, BUFSZ, VX_FCL_FILEOPEN_MASK | \

      VX_FCL_ACCESSINFO_MASK, &nentries);

Off host processing

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

# rcp savefile offhost-path

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.

Warning: 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.