As part of the IBM i software announcements made last week, the IFS now supports a temporary file system in IBM i 6.1. To use this support, you must apply PTF SI34983 to your IBM i 6.1 system. This is part of the base operating systems for all releases after 6.1.
What is the temporary file system? To understand, it’s helpful to know what happens with objects that exist in a traditional (we sometimes call it permanent) file system.
The IFS must perform many disk operations to ensure the integrity of the objects. For objects that are created only to be deleted a short time later, the disk operations can slow down an application. The temporary file system is a special type of user-defined file system (UDFS), which contains temporary objects that are automatically deleted by the system when the system is restarted or the file system is unmounted. Since objects are temporary, the disk operations aren’t required, and applications that use temporary objects may be able to increase their performance. A temporary file system isn’t intended for objects that contain critical data that must persist across an IPL.
Since the create and destroy of any object in a temporary file system will be faster, applications that create and destroy a large number of objects will see the most improvement in performance due to the large number of disk operations that are no longer required. In lab testing, we’ve seen some applications that create and destroy a large number of objects complete in half the time when using the temporary file system. The results for each application depend on what other processing is performed.
One possible use of this support would be to mount a temporary file system over the ‘/tmp’ directory so that the behavior of that directory would be more like other platforms. On IBM i, however, you’re not limited to a single temporary file system.
Temporary UDFSs are created and can be used much like the permanent UDFSs. The Create User-Defined FS (CRTUDFS) command is used to create a temporary UDFS specifying the extension .tmpudfs for the name. Permanent UDFSs must end with .udfs. For example:
CRTUDFS UDFS('/dev/QASP01/mynew.tmpudfs')
Only users who have *ALLOBJ special authority are allowed to create a temporary UDFS, and they must be created in the system auxiliary storage pool (ASP).
The Add Mounted FS (MOUNT) command is then used to mount the temporary UDFS into the namespace. For example, to mount the temporary UDFS created above over the directory ‘/mytemporaryfilesystem’:
MOUNT TYPE(*UDFS) MFS('/dev/QASP01/mynew.tmpudfs') MNTOVRDIR ('/mytemporaryfilesystem')
Now any objects created under ‘/mytemporaryfilesystem’ will be temporary objects. The temporary UDFS may not be mounted as a read-only file system. This makes sense because there are no objects in the temporary UDFS when it’s mounted.
The Remove Mounted FS (UNMOUNT) command may be used to manually unmount the temporary UDFS if you don’t wish to wait for an IPL of the system. For example:
UNMOUNT TYPE(*UDFS) MNTOVRDIR('/mytemporaryfilesystem')
As stated earlier, unmounting a temporary UDFS will delete all of the objects in it. If there are a large number of objects, this could be a long-running operation and could affect other processes on the systems that are attempting to access mounted file systems, including system-supplied file systems such as QSYS.LIB or QDLS. You can avoid this delay by deleting all the objects first. Additionally, the unmount of a temporary UDFS requires the same authorization as the Delete User-Defined FS (DLTUDFS) command since it will be performing the same function. This means the user will need enough authority to the objects within the UDFS to delete them. If the user issuing the UNMOUNT command doesn’t have the required authority, the command will fail and diagnostic messages will be sent to the joblog indicating the cause of the failure as well as a message indicating how many objects were removed.
It should also be pointed out that the Reclaim Storage (RCLSTG) command automatically forces all mounted file systems to be unmounted, including all UDFSs.
Users of temporary file systems must also be aware that the storage for the objects isn’t accounted for against the owning user profile’s maximum storage allowed, nor against the process. Therefore, it’s possible for a user to own objects whose storage totals more than the maximum allowed for the user profile. The Retrieve Directory Information (RTVDIRINF) command can be used to manage this storage.
Objects in a temporary UDFS can be secured like any other object in the IFS with one exception. Objects in a temporary UDFS may not be secured with an authorization list. Otherwise, the owner and primary group may be assigned as well as user and *PUBLIC authority.
Other restrictions include:
- Users may not save objects from, nor restore objects into, a temporary file system.
- User journaling of temporary objects isn’t allowed.
- Extended attributes aren’t supported for temporary objects.
- Object signing of temporary objects isn’t allowed.
Is a temporary file system a good fit for you? It’d be impossible to list all the situations where a temporary file system may be used, but if you (or your application) use integrated file system objects that are considered temporary and contain noncritical data, then you may want to consider using a temporary file system for those objects.
Read more about Temporary File System in the IBM i Knowledge Center.
The author of this week’s post is Margaret Fenlon. Margaret is the team leader of the IFS and servers development team in the IBM i development lab. Thanks, Margaret!
This post was edited for currency on January 26, 2020.
This blog post was originally published on IBMSystemsMag.com and is reproduced here by permission of IBM Systems Media.