Files are contained within mounted file systems, and the collection
of all the files in all the mounted file systems forms the z/OS UNIX file hierarchy.
The LFS structures for files and file systems are not directly
addressable by a VFS server. Consequently, files and file systems
are abstracted somewhat on the VFS callable services API.
A file is represented to a VFS server by a vnode token with the
following characteristics:
- A vnode token is similar to a POSIX file descriptor, in that it
is the main input to all calls that refer to the file.
- Vnode tokens are obtained most often from v_get() and v_lookup(),
but also from v_rpn(), v_create(), and v_mkdir()
- Vnode tokens are not inherited across fork().
- Vnode tokens are released with v_rel(). All
vnode tokens that are obtained must eventually be released. After v_rel() is
called, any subsequent call with the same vnode token fails.
- A single vnode token may be cached by the VFS server and shared
among many end users. A single vnode token can be used by several
tasks at the same time, but v_rel() is mutually
exclusive with all other operations.
- Many different vnode tokens can be obtained for the same file.
- A vnode token that has not been released is always valid for a
call in the sense that the VFS server program will not abnormally
end from using it.
Files that are deleted are still accessible
with existing vnode tokens. This is the same behavior that is expected
for POSIX file descriptors that have not been closed. If the underlying
real file system is unmounted with IMMEDIATE or FORCE, however, calls
that are made with vnode tokens for files in that file system fail
with an error code.
A file system is represented to a VFS server by a VFS token with
the following characteristics: