Temporary user-defined file systems

The temporary user-defined file system can increase performance by reducing auxiliary storage operations.

The integrated file system performs auxiliary storage operations to ensure that files and directories persist across IPLs or crashes of the system. However, many applications use temporary working files and directories that do not need to persist across IPLs of the system. These applications are needlessly slowed down by objects being forced to permanent storage. Users can create and mount a special type of UDFS that contains only temporary objects. Temporary objects do not require any extra auxiliary storage operations because they are automatically deleted by the system when the system is restarted, or when the file system is unmounted.

A temporary file system is created with the "Create User-Defined FS (CRTUDFS)" command using a new naming convention. The names of permanent UDFSs must end with ".udfs". The names of temporary UDFS's must end with ".tmpudfs", for example:
         CRTUDFS UDFS('/dev/QASP01/new.tmpudfs')

The creator of a temporary UDFS must have *ALLOBJ special authority. Temporary UDFSs can only be created in the system auxiliary storage pool (ASP). That is, they can only be created in '/dev/QASP01'.

After it is created, the temporary UDFS can then be mounted and used much like a permanent UDFS, with the following restrictions:

  • Temporary objects cannot be secured by authorization lists.
  • User journaling of temporary objects is not allowed.
  • Objects cannot be saved from, nor restored into, a temporary file system.
  • Extended attributes are not supported for temporary objects.
  • Object signing of temporary objects is not allowed.
  • You cannot mount a temporary UDFS as a read-only file system.

Users of temporary file systems need to be aware of the following considerations:

  • The storage for temporary objects is not accounted to the owning user profile nor to any process. Therefore, it is possible for a user profile to create temporary objects that exceed the maximum storage allowed for that user profile.
  • When any file system is unmounted, it can cause delays in other processes that are attempting to access mounted file systems, including system-supplied file systems such as QDLS or QSYS.LIB. Normally these delays are brief and are not noticeable. When a temporary UDFS is unmounted, all the contents of the UDFS are deleted. If there are large numbers of objects in the temporary UDFS, other processes could experience significant delays accessing other file systems. If you are affected by this consideration, it is recommended that you use the Remove Directory (RMVDIR) and Remove Link (RMVLNK) commands as needed to delete the contents of the temporary UDFS before unmounting the file system. The SUBTREE(*ALL) value for the RMVDIR command can be especially helpful in this regard.
  • Because unmounting a temporary UDFS deletes the entire contents of the UDFS, the unmount operation is subject to many of the same restrictions as the Delete User-Defined FS (DLTUDFS) command. The unmount can fail if any of the following are true:
    • The user does not have *OBJEXIST authority to all the objects in the UDFS.
    • The user does not have *WX data authority to all the non-empty directories in the UDFS.
    • Any object in the UDFS is checked out.
    • Any object in the UDFS is read-only.
    • The "restricted rename and unlink" attribute of a directory is "Yes", and the user is not the owner of the directory, does not own all the objects in the directory, and does not have *ALLOBJ special authority.
    When the unmount fails for any of these reasons, diagnostic messages can appear in the job log stating the reason for the failure, along with a message stating how many objects have been removed.
  • The block special file (BLKSF) object associated with the temporary UDFS is itself a permanent object. It is only the contents of the UDFS that are temporary. However, this BLKSF cannot be saved nor can its attributes be changed to allow it to be saved. Also, this BLKSF cannot be secured by an authorization list.