User-defined file systems (UDFSs)
The user-defined file systems (UDFSs) reside on the auxiliary storage pool (ASP) or independent auxiliary storage pool (ASP) of your choice. You can create and manage these file systems.
In addition, they:
- Provide a hierarchical directory structure similar to PC operating systems such as DOS and OS/2
- Are optimized for stream file input and output
- Support multiple hard links and symbolic links
- Support local sockets
- Support threadsafe APIs
- Support *FIFO objects
- Support the journaling of object changes
- Support the scanning of objects using the integrated file system scan-related exit points
You can create multiple UDFSs by giving each a unique name. You can specify other attributes for a UDFS during its creation, including:
- An ASP number or independent ASP name where the objects that are located in the UDFS are stored.
- The case-sensitivity characteristics of the object names that are located
within a UDFS.
The case-sensitivity of a UDFS determines whether uppercase and lowercase characters will match when searching for object names within the UDFS.
- The create object scanning attribute which defines what the scan attribute should be for objects created in a UDFS.
- The value for the restricted, rename and unlink attribute
- The auditing value for an object created in the UDFS.
- The different format, *TYPE1 and *TYPE2, for stream files created in the UDFS.
- The disk storage option for stream files created in the UDFS.
- The main storage option for stream files created in the UDFS.
User-defined file system concepts
In a user-defined file system (UDFS), as in the "root" (/) and QOpenSys file systems, you can create directories, stream files, symbolic links, local sockets, and *FIFO objects.
A single block special file object (*BLKSF) represents a UDFS. As you create UDFSs, you also automatically create block special files. The block special file is only accessible to the user through the integrated file system generic commands, APIs, and the QFileSvr.400 interface.
A UDFS exists only in two states: mounted and unmounted. When you mount a UDFS, the objects within it are accessible. When you unmount a UDFS, the objects within it become inaccessible.
In order to access the objects within a UDFS, you must mount the UDFS on a directory (for example, /home/JON). When you mount a UDFS on a directory, the original contents of that directory, including objects and subdirectories, become inaccessible. When you mount a UDFS, the contents of the UDFS become accessible through the directory path that you mount the UDFS over. For example, the /home/JON directory contains a file /home/JON/payroll. A UDFS contains three directories mail, action, and outgoing. After mounting the UDFS on /home/JON, the /home/JON/payroll file is inaccessible, and the three UDFS directories become accessible as /home/JON/mail, /home/JON/action, and /home/JON/outgoing. After unmounting the UDFS, the /home/JON/payroll file is accessible again, and the three directories in the UDFS become inaccessible.
An initial program load (IPL) of the system or a Reclaim Storage (RCLSTG) operation of the directories unmounts all UDFSs. Therefore, the UDFSs need to be remounted after performing an IPL or running a RCLSTG command on the directories.
Accessing a user-defined file system through the integrated file system interface
A user-defined file system (UDFS) can be accessed through the integrated file system interface using either the IBM® i file server or the integrated file system commands, user displays, and APIs.
In using the integrated file system interface, you should be aware of the following considerations and limitations.