If the PFS allows the LFS to share its files in a sysplex Shared
File System configuration, the following additional considerations
apply to cross-system support:
- If an LFS client system leaves the sysplex, all opens that were
done at the LFS owner for users at the lost client are closed. These
closes must be correlated by the PFS to the open context to which
they belong. The following interface is used to accomplish this:
Note: The PFS is also responsible for cleaning up any
remaining open contexts on vn_inact of a vnode. These open contexts
can persist for a long period of time. To avoid accumulating an indeterminate
number of orphaned open contexts in the PFS, this vn_close is done
when an LFS client abnormally terminates.
- If an LFS client system is at an earlier release level where the
Open_token is not supported, the client does not store or pass back
the Open_token. Consequently, all vnode operations from the LFS owner
to the PFS for this client will pass a 0 for the Open_token.
Since
the Open_token is not usable in this configuration, a flag, osi_otstateless, is passed to the PFS on vn_open to indicate that this is a
"stateless" client, and the PFS does not return an Open_token or expect
one to be passed to it on future vnode operations. The osi_otstateless flag is also set for vn_closes from this client.
- If an LFS server system leaves the sysplex, current vnode references
at the remaining client systems are broken, and current users receive
RC=EIO for any future file operations.
To summarize, the following information can be passed to the PFS
in the
osi_opentoken field: - For vn_open:
- 0
- A non-sysplex open() or a local open() at
the LFS owner.
- sysid
- A remote LFS client open being done at an LFS owner.
- sysid & stateless
- An open from an LFS client that does not support open tokens
is being done at an LFS owner.
- For vn_close:
- Open_token
- A regular vn_close when the Open_token is available.
- sysid
- A mass vn_close at an LFS owner for all opens from that sysid.
- sysid & stateless
- A vn_close from an LFS client that does not support open tokens
is being done at an LFS owner.