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
- 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.