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.
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.
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!
Connect With Us: