Veritas™ File System 5.0.1 Programmer's Reference Guide HP-UX 11i v3 HP Part Number: 5900-0399 Published: November 2009 Edition: 1.
© Copyright 2009 Hewlett-Packard Development Company, L.P. Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation and Technical Data for Commercial Items are licensed to the U.S. Government under vendor’s standard commercial license. The information contained herein is subject to change without notice.
Contents Technical Support ............................................................................................... 4 Chapter 1 Veritas File System software developer’s kit ................. 11 About the software developer’s kit .................................................. File System software developer’s kit features .................................... API library interfaces .............................................................. File Change Log ......................................
8 Contents vxfs_inotopath_gen ................................................................ 49 Chapter 3 Multi-volume support ......................................................... 51 About multi-volume support .......................................................... Uses for multi-volume support ....................................................... Volume application programming interfaces ..................................... Administering volume sets ........................................
Contents Reservation: preallocating space to a file .................................... Fixed extent size .................................................................... Application programming interface for extent attributes .............. Allocation flags ...................................................................... Allocation flags with fixed extent size ........................................ How to use extent attribute APIs ...............................................
10 Contents
Chapter 1 Veritas File System software developer’s kit This chapter includes the following topics: ■ About the software developer’s kit ■ File System software developer’s kit features ■ Software developer’s kit packages ■ Required libraries and header files ■ Compiling environment About the software developer’s kit Veritas File System (VxFS) Software Developer’s Kit (SDK) provides developers with the information necessary to use the application programming interfaces (APIs) to modify and tune va
12 Veritas File System software developer’s kit File System software developer’s kit features API library interfaces The API library interfaces highlighted in this SDK are the vxfsutil library and VxFS IOCTL directives. The library contains a collection of API calls that applications can use to take advantage of the features of the VxFS file system. Manual pages are available for all of the API interfaces. Table 1-1 describes the API calls and features available in the VxFS API library.
Veritas File System software developer’s kit Software developer’s kit packages See “About the File Change Log file” on page 17. Multi-volume support The multi-volume support (MVS) feature allows a VxFS file system to use multiple Veritas™ Volume Manager (VxVM) volumes as underlying storage. Administrators and applications can control where files go to maximize effective performance, while minimizing cost. This feature can be used only with Veritas Volume Manager.
14 Veritas File System software developer’s kit Required libraries and header files Required libraries and header files The VRTSfssdk package is installed in the /opt directory. The associated libraries and header files are installed in the following locations: ■ /opt/VRTSfssdk/5.0/lib/libvxfsutil.a ■ /opt/VRTSfssdk/5.0/include/vxfsutil.h ■ /opt/VRTSfssdk/5.0/include/sys/fs/fcl.h ■ /opt/VRTSfssdk/5.0/include/sys/fs/vx_ioctl.
Veritas File System software developer’s kit Compiling environment To compile the src or libsrc directory, edit the /opt/VRTSfssdk/4.1/make.env file as follows: 1 Select the compiler path on your local system. choose and edit CC to the path on your system.
16 Veritas File System software developer’s kit Compiling environment
Chapter 2 File Change Log This chapter includes the following topics: ■ About the File Change Log file ■ Record types ■ File Change Log tunables ■ Application programming interface for File Change Log ■ Reverse path name lookup About the File Change Log file The VxFS File Change Log (FCL) tracks changes to files and directories in a file system.
18 File Change Log About the File Change Log file ■ Creates ■ Links ■ Unlinks ■ Renaming ■ Data appended ■ Data overwritten ■ Data truncated ■ Extended attribute modifications ■ Holes punched ■ Miscellaneous file property updates Note: The FCL is supported only on disk layout Version 6 and later. The FCL stores changes in a sparse file, referred to as the FCL file, in the file system namespace. The FCL file is always located in /mount_point/lost+found/changelog.
File Change Log About the File Change Log file For example, an incremental backup application can scan the FCL file to determine which files have been added or modified since the file system was last backed up. ■ Configure the FCL to track additional information, such as file opens, I/O statistics, and access information, such as user ID. You can then use this information to gather the following data: ■ Space usage statistics to determine how the space usage for different types of data.
20 File Change Log About the File Change Log file See the fcladm(1M) manual page. When FCL loggin is activated, new FCL records are appended to the FCL file as file system changes occur. When FCL logging is turned off, further recording stops, but the FCL file remains as /lost+found/changelog. You can only remove an FCL file by using the fcladm command.
File Change Log About the File Change Log file The FCL file is usually a sparse file containing the FCL superblock and the FCL records. The first information block in the FCL file is the FCL superblock. This block may be followed by an optional hole as well as the FCL records which contain information about the changes in the file system. Figure 2-1 depicts the FCL file format.
22 File Change Log Record types As the FCL file grows in size, depending on the file system tunables fcl_maxalloc and fcl_keeptime, the oldest records at the start of the FCL file are thrown away to free up some space, as the first offset gets updated. When the set of events tracked in the FCL file is changed using the [set] or [clear] options of the fcladm command, the event mask and the event mask change time are updated.
File Change Log Record types Table 2-1 FCL record types (continued) Action to create an FCL record Record type Create a named data stream directory VX_FCL_CREATE Create a symbolic link VX_FCL_SYMLINK Perform an mmap on a file in a shared and writable mode VX_FCL_DATA_OVERWRITE Promote a file from a Storage Checkpoint VX_FCL_UNDELETE Punch a hole into a file VX_FCL_HOLE_PUNCHED Remove a file or directory VX_FCL_UNLINK Remove a named data stream directory VX_FCL_UNLINK Rename a file or dire
24 File Change Log Record types Table 2-1 FCL record types (continued) Action to create an FCL record Record type Change the set of events tracked in VX_FCL_EVNTMSK_CHG the FCL Note: Table 2-1 lists all the events recorded by default when the fcladm on command activates FCL logging, except fileopen and filestat. Access information for each of these events is also not recorded by default. Use the [set] option of the fcladm command to record opens, I/O statistics and access information.
File Change Log File Change Log tunables VX_FCL_DATA_EXTNDWRITE VX_FCL_DATA_OVERWRITE The following shows a typical sequence of FCL records written to the log, when file a is renamed to b and both files are in the file system: VX FCL_UNLINK (for file b, if it already exists) VX_FCL_RENAME (for a rename from a to b) File Change Log tunables You can set four FCL tunable parameters using the vxtunefs command. See the vxtunefs(1M) manual page.
26 File Change Log File Change Log tunables fcl_winterval 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.
File Change Log Application programming interface for File Change Log feature only purges records that are older than a time specified by fcl_keeptime. The freed space is always in units of an internal hole size. Figure 2-2 displays the file system freeing up space in the FCL file in 8K units. When the FCL file surpasses the maximum allocation for the first time and the number of older records is 20K, the program purges 16K. This leaves a 16K hole following the FCL superblock.
28 File Change Log Application programming interface for File Change Log be of variable sizes, such as a file remove or rename record. These records contain additional information, such as the name of a file that is removed or renamed. To ensure that the first few bytes at the start of any file system block is always a valid FCL record (if the filename crosses a block boundary), the file system block may be split across multiple on-disk records.
File Change Log Application programming interface for File Change Log vxfs_fcl_getinfo Returns the FCL version number along with the state (on/off) of the FCL file vxfs_fcl_read Reads FCL records of interest to the user into a buffer passed in by the user vxfs_fcl_copyrec Copies an FCL record. If the source record contains pointers, it relocates them to point to the new location.
30 File Change Log Application programming interface for File Change Log meta-information about the FCL file into an opaque internal data structure and populates **handle with a pointer. Just like the lseek(2) and read(2) system calls, the FCL file **handle has an internal offset to indicate the position in the file from where the next read starts. When the FCL file is successfully opened, this offset is set to the first valid offset in the FCL file.
File Change Log Application programming interface for File Change Log 31 Return values A “0” indicates success; otherwise, the errno is set to error and a non-zero value is returned. vxfs_fcl_read This function lets the application read the actual file or directory change information recorded in the FCL as logical records. Each record returns a struct fcl_record type. vxfs_fcl_read lets the application specify a filter comprising a set of desired events.
32 File Change Log Application programming interface for File Change Log ■ *nentries specifies the number of entries that should be read into the buffer in this call to vxfs_fcl_read. If *nentries is “0,” vxfs_fcl_read reads as many entries as well fit in the buffer. Output *buf contains *nentries FCL records of the struct fcl_record type if there is no error. If the requested number of entries cannot fit in a buffer of the passed size, an FCL_ENOSPC error is returned.
File Change Log Application programming interface for File Change Log 33 information about the current position in the FCL file using vxfs_fcl_getcookie and then store the cookie in a persistent structure such as a file. The next time the application needs to perform an incremental operation, it reads the cookie and passes it to vxfs_fcl_seek to seek to the point where it left off. This enables the application to read only the new FCL records.
34 File Change Log Application programming interface for File Change Log ■ The *cookie parameter should point to a valid cookie that has been returned from a call to vxfs_fcl_getcookie() on the same FCL file or one of its checkpoints or one of the dumped or restored copies of the same FCL file. It is the responsibility of the user application to decide which FCL file is valid for a particular cookie and to use them in a sensible combination.
File Change Log Application programming interface for File Change Log int vxfs_fcl_seektime(void *handle, struct fcl_timeval time) The function parameters are as follows: ■ *handle is a valid handle returned by a previous call to vxfs_fcl_open ■ time is an fcl_time_t structure type defined as follows: struct fcl_time { uint32_t tv sec; unit32_t tv_nsec; } fcl_time t; Note: The time specified in fcl_time_t is in seconds or nanoseconds, while the time that is returned by a standard system call such as g
36 File Change Log Application programming interface for File Change Log vxfs_fcl_sync The vxfs_fcl_sync function sets a synchronization point within the FCL file. This function is kept for backward compatibility. Before the availability of the VxFS 5.0 API to access the FCL file, applications would typically call vxfs_fcl_sync to get the FCL to a stable state and set an offset in the FCL file to use as a reference point to stop reading.
File Change Log Application programming interface for File Change Log uint16_t fr_op; /* Operation type. */ uint16_t fr_unused1; /* unused field */ uint32_t fr_acsinfovalid : 1; /* fr_acsinfo field valid */ uint32_t fr_newnmvalid : 1; /* fr_newfilename field is valid */ uint32_t fr_pinogenvalid : 1; /* fr_fr_pinogen field is valid */ uint32_t fr_unused2 : 29; /* Future use */ uint64_t fr_inonum; /* Inode Number. */ uint32_t fr_inogen; /* Inode Generation Count. */ fcl_time_t fr_time; /* Time.
38 File Change Log Application programming interface for File Change Log fcl_iostats structure VxFS 5.0 lets you gather statistics such as the number of reads / writes occurring on a file. You can enable this through the fiostat command. The gathered stats are maintained in a per-file in-core structure and the File Change Log acts as a persistent backing store for the statistics.
File Change Log Application programming interface for File Change Log The aggregation considers values only from the latest record from records with the same lastreset time and then sums up the number of reads for each such record.
40 File Change Log Application programming interface for File Change Log Figure 2-3 Sample link record The following code sample traverses the set of records returned by a call to vxfs_fcl_read and prints the user ID: Struct fcl_record*fr; Char *tbuf; ...
File Change Log Application programming interface for File Change Log See “vxfs_fcl_read” on page 31. Record structure fields Table 2-2 briefly describes each field of the fcl_record structure and indicates the record types for which it is valid. Table 2-2 FCL record structure fields Field Description Validity fr_reclen Length of the FCL record. This Valid for all records. includes length of the FCL record structure and length of the data stored immediately following the structure.
42 File Change Log Application programming interface for File Change Log Table 2-2 FCL record structure fields (continued) Field Description Validity fr_inogen The generation count of the changed file. The generation count in combination with the inode number (of the file) is passed to vxfs_inotopath_gen to provide the exact full path name of the object. Without the generation count, the returned path name can be a re-used inode. Valid for all FCL records except for event mask changes and unlinks.
File Change Log Application programming interface for File Change Log Table 2-2 FCL record structure fields (continued) Field Description fr_stats A pointer to an FCL_iostat Valid only when the FCL record is record. The fcl_iostat record VX_FCL_FILESTATS. contains I/O statistics such as the number of reads / writes that happened on the file, average time for a read / write, etc. These point-in-time records can be used to compute the aggregate or average I/O statistics for a file over a period of time.
44 File Change Log Application programming interface for File Change Log 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.
File Change Log Application programming interface for File Change Log 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)); Computing a usage profile This sample application computes the usage profile of a particular file, that is, the users who have accessed a particular file in the last hour.
46 File Change Log Application programming interface for File Change Log Sample application setup 1 Open the FCL file. vxfs_fcl_open(mntpt, 0, &fh); 2 Set up the time to perform the seek. 3 Get current time using gettimeofday. 4 Fabricate the fcl_time_t for the time an hour before. 5 Seek to the record in the FCL file at that time. gettimeofday(&tm, NULL); tm.sec -= 3600 vxfs_fcl_seektime(fh, tm); 6 Read the file with the appropriate event masks until the end of file is reached.
File Change Log Application programming interface for File Change Log 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 filenames from the inode number.
48 File Change Log Reverse path name lookup Downgrading Veritas File System versions In the future, the VxFS version on a particular system may need to be downgraded from a newer VxFS release (for example, VxFS 6.0) to VxFS 5.0. This may happen when a file system is migrated from one operating system using VxFS 6.0 to another using VxFS 5.0. If the FCL file created by this future VxFS version is Version 3 or 4, it can then be used (as is) by the VxFS 5.0 installation.
File Change Log Reverse path name lookup A file inode number, generation count, and, in the case of a VX_FCL_LINK, VX_FCL_UNLINK, or VX_FCL_RENAME record, trailing filename, when combined with the use of reverse path name lookup, can generate full path names for each FCL record.
50 File Change Log Reverse path name lookup
Chapter 3 Multi-volume support This chapter includes the following topics: ■ About multi-volume support ■ Uses for multi-volume support ■ Volume application programming interfaces ■ Allocation policy application programming interfaces ■ Data structures ■ Using policies and application programming interfaces About multi-volume support The multi-volume support (MVS) feature lets a VxFS file system use multiple VxVM volumes as underlying storage instead of the traditional single volume per file s
52 Multi-volume support Uses for multi-volume support ■ Per-file-system policies The most specific allocation policy in effect for a given allocation operation is used. The MVS APIs fall into the following basic categories: ■ Manipulation of volumes within a file system ■ Manipulation of allocation policy definitions ■ Application of allocation policies Each of the APIs is also available via options to the fsvoladm(1M) and fsapadm(1M) commands. See the fsvoladm(1M) and fsapadm(1M) manual pages.
Multi-volume support Volume application programming interfaces Administering volume sets The following examples show how to administer volume sets.
54 Multi-volume support Allocation policy application programming interfaces To grow or shrink a volume ■ To grow or shrink a volume, use the following function call: vxfs_vol_resize(fd, vol_name, new_vol_size); To remove a volume from a file system ■ To remove a volume from a file system, use the following function call: vxfs_vol_remove(fd, vol_name); Add a volume to a file system ■ To add a volume to a file system, use the following function call: vxfs_vol_add(fd, new_vol_name, new_vol_size); Enca
Multi-volume support Allocation policy application programming interfaces if a policy is assigned to a single file, the file system must know where to place both the file data and metadata. If no policies are specified, the file system places data randomly. The allocation policies are defined per file system and are persistent. There is no fixed limit on the number of allocation policy definitions in a file system. Once a policy is assigned, new file allocations are governed by the policy.
56 Multi-volume support Allocation policy application programming interfaces When file4 is created, the initial allocation is on vol-01 and vol-02. To move file4 to vol-03, assign policy3 to file4 and enforce that policy on the file. This reallocates file4 to vol-03. To direct file allocations 1 Create the allocation policies on the /mnt file system. 2 Assign the data and metadata allocation policies to the /mnt file system as policy1 and policy2.
Multi-volume support Allocation policy application programming interfaces 57 vxfs_ap_assign_ckptchain(fd, data_policy, meta_policy); ■ To set the default allocation policies for newly created Storage Checkpoints, use the following function call: vxfs_ap_assign_ckptdef(fd, data_policy, meta_policy); Querying the defined policies The following function calls query defined policies.
58 Multi-volume support Data structures Enforcing the policy may cause the file to be reallocated to another volume.
Multi-volume support Using policies and application programming interfaces Using policies and application programming interfaces The following examples assume there is a volume set, volset, with the volumes vol-01, vol-02, and vol-03. The file system mount point /mnt is mounted on volset. Defining and assigning allocation policies The following pseudocode provides an example of using the allocation policy APIs to define and assign allocation policies.
60 Multi-volume support Using policies and application programming interfaces fd = open("/mnt", O_RDONLY); dir_fd = open("/mnt/dir1", O_RDONLY); vxfs_ap_define(fd, &ap, 0); /* Create the mirror policy */ strcpy((char *) ap.ap_name, "Mirror_Policy"); ap.ap_flags = FSAP_CREATE | FSAP_INHERIT; ap.ap_order = FSAP_ORDER_ASGIVEN; ap.ap_ndevs = 1; strcpy(ap.
Multi-volume support Using policies and application programming interfaces To encapsulate a raw volume as a file 1 Add the volume to the volume set. 2 To encapsulate a raw volume vol-03 as a file named encapsulate_name in the file system /mnt, create code similar to the following: /* Take the raw volume vol-03 and encapsulate it. The volume’s contents will be accessible through the given path name.
62 Multi-volume support Using policies and application programming interfaces
Chapter 4 Named data streams This chapter includes the following topics: ■ About named data streams ■ Uses for named data streams ■ Named data streams application programming interface ■ Listing named data streams ■ Namespace for named data streams ■ Behavior changes in other system calls ■ Querying named data streams ■ Application programming interface ■ Command reference About named data streams Named data streams associate multiple data streams with a file.
64 Named data streams Uses for named data streams Figure 4-1 file1 data_stream_1 Alternate Namespace / Alternate namespace for named data streams data_stream_2 The file1 file has two named data streams: data_stream_1 and data_stream_2. Every file can have its own alternate namespace to store named data streams. The alternate namespace can be accessed through the named data stream APIs supported by VxFS.
Named data streams Named data streams application programming interface open() Opens a named data stream read() Reads a named data stream write() Writes a named data stream getdents() Reads directory entries and puts in a file system independent format mmap() Maps pages of memory readdir() Reads a directory VxFS named data stream functionality is available through the following application programming interface functions: vxfs_nattr_open() Works similarly to the open() system call, except that
66 Named data streams Listing named data streams vxfs_nattr_unlink() Removes the named data stream at a specified path. The calling function must have write permission to remove the directory entry for the named data stream. The following is the syntax for the vxfs_nattr_unlink() API: int vxfs_nattr_unlink(int fd, char *path); vxfs_nattr_rename() Changes a specified namespace entry at path1 to a second specified namespace at path2.
Named data streams Namespace for named data streams To list named data streams 1 To list the named data streams, create code similar to the following: fd = open("foo", O_RDWR); /* open file foo */ afd = vxfs_nattr_open(fd, "stream1", O_RDWR|O_CREAT, 0777);/* create named data stream stream1 for file foo */ write(afd, buf, 1024); /* writes to named stream file */ read(afd, buf, 1024); /* reads from named stream file */ dfd = vxfs_nattr_open(fd, ".
68 Named data streams Querying named data streams dirp = opendir("."); readdir_r(dirp, (struct dirent *)&entry, &result); Note: The usage section of the getcwd(3C) man page states that applications should exercise care when using the chdir() call in conjunction with getcwd(). The current working directory is global to all threads within a process. If more than one thread calls chdir() to change the working directory, a subsequent call to getcwd() could produce unexpected results.
Named data streams Application programming interface Application programming interface The named data streams API uses a combination of standard system calls and VxFS API calls to utilize its functionality.
70 Named data streams Command reference
Chapter 5 Veritas File System I/O This chapter includes the following topics: ■ About Veritas File System I/O ■ Freeze and thaw ■ Caching advisories ■ Extents About Veritas File System I/O Veritas File System (VxFS) I/O controls the access of data on a VxFS file system. VxFS APIs are provided for freezing and thawing file systems, administering caching advisories, and administering extent attributes.
72 Veritas File System I/O Freeze and thaw file system cache that contain dirty metadata and user data. The operation then suspends any new activity on the file system until the file system is thawed. VxFS provides ioctl interfaces to application programs to freeze and thaw VxFS file systems. The interfaces are VX_FREEZE, VX_FREEZE_ALL, and VX_THAW. The VX_FREEZE ioctl operates on a single file system.
Veritas File System I/O Caching advisories include int timeout; int vxfs_fd; /* * A common mistake is to pass the address of "timeout". * Do not pass the address of timeout, as that would be * interpreted as a very long timeout period */ if (ioctl(vxfs_fd, VX_FREEZE, timeout)) {perror("ERROR: File system freeze failed"); } For multiple file systems: int vxfs_fd[NUM_FILE_SYSTEMS]; struct vx_freezeall freeze_info; freeze_info.num = NUM_FILE_SYSTEMS freeze_info.
74 Veritas File System I/O Caching advisories applications use the last advisory that was set on the file. VxFS does not coordinate or prioritize advisories. Some advisories are not cleared from memory after the last close of the file. Recorded advisories remain in memory for as long as the file system metadata used to manage access to the file remains in memory. Removing file system metadata for the file from memory is not predictable.
Veritas File System I/O Caching advisories Concurrent I/O Concurrent I/O (VX_CONCURRENT) is a form of I/O for file access. This form of I/O allows multiple processes to read or write to the same file without blocking other read() or write() operations. POSIX semantics requires read() and write() operations to be serialized on a file with other read() and write() operations. With POSIX semantics, a read will either read the data before or after the write occurs.
76 Veritas File System I/O Extents CIO is a licensable feature of VxFS. Unbuffered I/O The I/O behavior of the VX_UNBUFFERED advisory is the same as the VX_DIRECT advisory set with the same alignment constraints as direct I/O. However, for unbuffered I/O, if the file is extended, or storage is allocated to the file, metadata updates on the disk for extending the file are not performed synchronously before the write returns to the user.
Veritas File System I/O Extents logical blocks. Extents allow disk I/O to take place in units of multiple blocks if storage is allocated in consecutive blocks. For sequential I/O, multiple block operations are considerably faster than block-at-a-time operations. VxFS uses an aggressive allocation policy for allocating extents to files. It also allows an application to pre-allocate space or request contiguous space.
78 Veritas File System I/O Extents ■ The space reserved for a file must be contiguous ■ No allocations are made for a file beyond the current reservation ■ An unused reservation is released when the file is closed ■ Space is allocated, but no reservation is assigned ■ The file size is changed to immediately incorporate the allocated space Some of the extent attributes are persistent and become part of the on-disk information about the file, while other attributes are temporary and are lost after
Veritas File System I/O Extents is less than the reservation amount, space is allocated to the file from the current file size up to the reservation amount. When the file is truncated, space below the reserved amount is not freed. Fixed extent size VxFS uses the I/O size of write requests and the default allocation policy for allocating space to a file. For some applications, the default allocation policy may not be optimal.
80 Veritas File System I/O Extents Applications can set or change extent attributes on a file by providing the attribute information in the structure of type vx_ext and passing the VX_SETEXT iotcl and the address of the structure using the third argument of the ioctl() call. Applications can also retrieve existing extent attributes, if any, by passing the VX_GETEXT ioctl and the address of the same structure, of type vx_ext, as the third argument with the ioctl() call.
Veritas File System I/O Extents ■ Whether allocations are aligned ■ Whether allocations are contiguous ■ Whether the file can be written beyond its reservation ■ Whether an unused reservation is released when the file is closed ■ Whether the reservation is a persistent attribute of the file ■ When the space reserved for a file will actually become part of the file Allocation flags with reservation The VX_TRIM, VX_NOEXTEND, VX_CHGSIZE, VX_NORESERVE, VX_CONTIGUOUS, and VX_GROWFILE flags can be us
82 Veritas File System I/O Extents No write beyond reservation The VX_NOEXTEND flag specifies that any attempt to write beyond the current reservation must fail. Writing beyond the current reservation requires the allocation of new space for the file. To allocate new space to the file, the space reservation must be increased. This can be used similar to the function of the ulimit command to prevent a file from using too much space.
Veritas File System I/O Extents the current size of the file and the size after the operation succeeds). VX_GROWFILE has persistent effects, but is not visible as an allocation flag. This flag is visible through the VX_GETEXT ioctl. Allocation flags with fixed extent size The VX_ALIGN flag can be used to specify an allocation flag for fixed extent size. This flag has no effect if it is specified with a reservation request.
84 Veritas File System I/O Extents Setting fixed extent size The following is an example code snippet for setting the fixed extent size of the MY_PREFERRED_EXTSIZE attribute on a new file, MY_FILE, assuming MY_PREFFERED_EXTSIZE is multiple of the file system block size: #include struct vx_ext myext; fd = open(MY_FILE, O_CREAT, 0644); myext.ext_size = MY_PREFERRED_EXTSIZE; myext.reserve = 0; myext.
Chapter 6 Thin Reclamation This chapter includes the following topics: ■ About Thin Storage ■ About Thin Reclamation ■ Thin Reclamation application programming interface About Thin Storage Thin Storage is the result of using Thin Provisioning-capable arrays. Thin Storage is an array vendor solution for allocating storage to applications only when the storage is truly needed, from a pool of free storage.
86 Thin Reclamation Thin Reclamation application programming interface uint vxfs_ts_reclaim(char *mountpoint, uint64_t offset, uint64_t length, int32_t volindex, uint64_t unit_size, uint64_t *bytes_reclaimed, uint32_t flag) This is a non-reentrant API. This API cannot be called when an instance of the fsadm command or a reorg of the file system is running. mountpoint The pathname of the VxFS file system that is mounted on a Veritas Volume Manager (VxVM) volume.
Thin Reclamation Thin Reclamation application programming interface flag Possible value for flag is: ■ VXFS_TS_RECLAIM_AGGRESSIVE — Perform an additional data and metadata reorganization to maximize free space reclamation. This operation might trigger additional space allocation from the underlying Thin Storage, which is released at the end of the operation. This operation can fragment existing large allocations. Aggressive reclamation is performed only if VxVM reports the volume as thinrclm.
88 Thin Reclamation Thin Reclamation application programming interface ENOMEM Memory could not be allocated during the operation of the API. EBUSY The metadata on the file system could not be modified. ENXIO The specified device does not exist. EINVAL The specified offset or length is invalid. EAGAIN Another fsadm or reorg instance is running. EFAULT The reclaim operation failed due to other system-related issues.
Index A allocation flags 80 allocation flags with fixed extent size 83 allocation policies 51 multi-volume support 54 alternate namespace 63 application interface 12 FSAP_INHERIT 55 fsapadm 52 fsvoladm 52 G getcwd 68 getdents 65–66 getext 77 C caching advisories 73 close 18 compiling environment 14 concurrent I/O 75 D data copy 74 data transfer 74 DEV_BSIZE 77 direct data transfer 74 direct I/O 74 E extent attributes 77 extents 76 F fchdir 67 fchroot 67 fcl_keeptime 25 fcl_maxalloc 25 fcl_winterval 2
90 Index N named attributes 63 named data streams 63 application programming interface 64, 69 behavior changes in other system calls 67 example 68 listing 66 namespace 67 programmer’s reference 69 ncheck 48 O open 18, 63, 65, 74 other advisories 76 R read 18, 64–65, 75 readdir 65 Record Types special records 24 record types 22 reservation 77–78 reverse path name lookup 48 S sequential I/O 74, 77 setext 77 Software Developer’s Kit 11 packages 13 special records 24 statfs 83 Storage Checkpoints 52 synchr
Index W write 64–65, 75 91
