The Verix V platform employs a file manager that attempts to recover unused memory space to provide as much data storage space as possible. This space recovery helps ensure maximum transaction storage capacity. Be aware that when writing, inserting, and deleting data, any files or data stored after the current file pointer are moved. While the time required to move this data is normally imperceptible, the time delay is multiplied when performing multiple operations, such as in a loop. Also, as the application stores additional transaction data, the delay becomes longer as each transaction is added to the same file.
The file extension feature allows you to specify a maximum size for a file, as described in Support for File Extension Areas. If you use this feature, the required space is immediately claimed from the file system and is not available for other files. Future file operations on this file, however, do not disturb other files in the system.
To minimize potential delays resulting from file management routines to reclaim unused memory, observe the following guidelines:
• Place frequently updated files after any large data storage files; this minimizes the amount of data that must be moved during file management.
NOTE For increased performance, minimize the use of keyed files. After downloads, move frequently used data from CONFIG.SYS to more efficient files.
NOTE Files are added to the directory chronologically. Ensure that large or static files are created/downloaded before small dynamic files.
Default System Files
Support for File Groups
An application consists of one or more files, some of which can represent
executable code files. Verix V supports a Group ID (GID) feature that allows these files to be separated from files in other applications. The system supports 16 groups. Not all groups are alike; the system enforces the following special rules:
• Group 0 is the administrative group, reserved for operating system files provided by VeriFone
• Group 1 is the user group, intended for the primary application, typically belonging to the owner of the terminal. Another term often used is sponsor application
• Groups 2 through 14 are intended for other applications
• Group 15 can be used as a universal group
The primary feature provided by the Group ID is a private name space for
filenames. Within any particular file group, all filenames must be unique, but files from different groups are automatically distinct from one another. In practice, this gives each application a private file space, where all the tasks that are part of the application can see all of the application files, but tasks from outside the
application cannot.
Sometimes it is useful or even necessary to share visibility. The system call set_group() allows a task to obtain visibility into the file space of another group.
The policy pertaining to set_group() is summarized as:
• Tasks belonging to Group 1 (sponsoring application) can use set_group to access files in any group, except for Group 0
• Tasks belonging to any other group can use set_group to access files in Group 15 (universal application), as well as their own group
In addition, any file in Group 15 can be directly accessed if its name is
preceded by the slash (/) character. To open the file FOO in Group 15, specify /FOO in the open() statement without using a set_group operation.
Analogous to the set_group call is get_group, which retrieves the current (temporary) group setting for the caller.
Support for File Extension Areas
The Verix V file manager stores a file as a contiguous array of characters. When another file is created, it becomes another contiguous array, stored in memory immediately after the first. If the first array subsequently “grows” to accommodate new data, the newer file must be shifted. This means that updating one file can cause other files to slosh in memory. This design optimizes memory usage, but can significantly degrade system performance.
In Verix V, this problem is addressed with an optional file extension area that the user can specify to allow growth or shrinkage within a particular file without affecting other files in the system. The concept is simple: Provide a pad area at the end of the file and allow the system to adjust this pad area to accommodate changes in the amount of actual user data in the file.
FILE MANAGEMENT
Default System Files
The following discussion includes illustrations to clarify this concept. First, a typical file (OURFILE) is shown in Figure 4 as it appears within the system, preceded by older files and followed by newer files.
Figure 4 Typical File Space Usage
Notice the pad area at the end of OURFILE. In Verix V, an expansion region is supported (shown as the greyed pad area) for each file. Within the file header, separate counts are maintained, FhUsrSz and FhMaxSz, to indicate the amount of user data with and without the pad.
Verix V file systems support this pad area for all files to ensure that each file begins on an integer boundary. This allows retention of all file headers on word-aligned boundaries.
Every file has a pad area defined, although it can be zero bytes long. For a normal file (that is, one without the expansion area feature enabled), the pad is no more than three bytes long—just enough to keep the next file word-aligned.
The main purpose of supporting the pad area is that it can be substantially larger than three bytes long. The file manager supports a call to define a maximum space for user data value. That is, you can update the FhMaxSz field maintained in the file header. Two calls provide access to this field:
OLDER FILES
OURFILE
OURFILE USERDATA
HEADER
OURFILE PAD AREA
NEWER FILES
SYSTEM PAD AREA FhFilSz
FhMaxSz
FhUsrSz
Default System Files
Several rules apply to the use of set_file_max(), since not every value for maxuserdatasize is valid:
• If maxuserdatasize is 0:
• The pad area is minimized (to 3 bytes or less, just enough to ensure the file size is word-aligned), and
• ATTR_NO_GROW is reset, allowing future writes to change the size of the file (and move newer files).
• If the specified maxuserdatasize is at least as big as the current number of user data bytes in the file but is less than the current setting of FhMaxSz:
• The file shrinks to the new limit causing newer files to move, and
• ATTR_NO_GROW is set, freezing the size of the file to this new limit.
Note that if you attempt to reduce the total file size to less than the size of the current data, the call is rejected, a result of –1 returns with errno set to
EINVAL.
• If the specified maxuserdatasize is the same as the current setting of FhMaxSz or larger:
• The system attempts to expand the file, causing newer files to move, and
• If sufficient space exists, ATTR_NO_GROW is set, freezing the size of the file to this new limit, and
• If not enough space in the file system exists to accommodate the request, the call is rejected, a result of –1 returned with errno set to ENOSPC. Consider what happens to the file once set_file_max() is called to define a pad area for expansion. Assume that some data must be added to the file using one of the write() or insert() calls. As long as the amount of data added is less than the current size of the pad, the system reduces the pad by just the amount required to accommodate the new data without changing the total size of the file.
Figure 5 illustrates this process.
FILE MANAGEMENT
Default System Files
Figure 5 New Data Added; Pad Area Shrinks
In this example, some existing user data shifts down since the data is not being inserted at the end of the file; the new data is then written into the file. Note that no other files in the system are affected. In particular, newer files, which occur after this file in memory, do not get sloshed (that is, moved back and forth in memory) just because the size of the file is changed.
Furthermore, various delete() operations can be issued to analogously cause the pad area to grow without affecting the total size of the file and without causing newer files to move.
Exceeding File Extension Area
An important issue to consider is what happens when the developer attempts to add a block of data larger than the designated pad.
If the ATTR_NO_GROW bit is set—which is normal after a call to set_file_max()— the write() or insert() call fails, a result of –1 returns with errno set to EFBIG. Note that this error code indicates specifically that the file’s expansion area would overflow; it does not imply that the system’s expansion area is full.
If the ATTR_NO_GROW bit is not set, for example because it was explicitly reset with
OLDER FILES
Default System Files
This process is illustrated in Figure 6. Note that in the right-most section of the diagram, OURFILE USERDATA pad area is smaller. In fact, the OURFILE USERDATA pad is never greater than one byte after the system moves newer files. It is possible, however, that the pre-existing pad area was only 0-byte long, so in this “small” sense, it is possible for the pad to grow.
Figure 6 Failed File Expansion
Notice that the user does have the option of controlling the ATTR_NO_GROW bit directly. This is largely a by-product of the implementation.
Although there is some value to being able to interrogate the state of this feature using the get_file_attributes() call, there is no advantage to using either set_file_attributes(..ATTR_NO_GROW) or
reset_file_attributes(..ATTR_NO_GROW), and their use not recommended.
Finally, users of this feature should note the error code: EFBIG. The caller’s errno is set to this value in only one situation: When an attempt to overflow the
maximum file size previously set using set_file_max(). This error code informs the user that the previous estimate was incorrect; the user must either expand the file or turn off the fixed expansion area feature. In either case, the user should employ the set_file_max() call once more, either passing a larger size to expand the terminal’s size area or passing a size of zero to disable the fixed-size limit (and allow newer files to slosh).
OLDER FILES
FILE MANAGEMENT
Variable-Length Records