z/OS V1R9.0 UNIX System Services Command ... - Christian Grothoff

mount
Usage notes
2. To mount an HFS file system over /u/wjs with a sync interval of 120 seconds:
mount -f omvs.hfs.user.wjs -o ’SYNC(120)’ /u/wjs
3. To display a list of pathnames for all mountpoints under /u:
mount -q /u
1. Systems exploiting shared file system will have I/O to an OMVS couple data
set. Because of these I/O operations to the CDS, each mount request requires
additional system overhead. You will need to consider the affect that this will
have on your recovery time if a large number of mounts are required on any
system participating in shared file system.
2. The –a unmount is not available to automounted file systems.
3. The –a no specification will only be accepted on z/OS V1R3 systems and later.
File system recovery and mount
File system recovery in a shared file system environment takes into consideration
file system specifications such as –a yes|no|unmount and whether or not the file
system is mounted read-only or read/write.
Generally, when an owning system fails, ownership over its –a yes mounted file
system is moved to another system and the file is usable. However, if a file system
is mounted read/write and the owning system fails, then all file system operations
for files in that file system will fail. This is because data integrity is lost when the file
system owner fails. All files should be closed (BPX1CLO) and reopened
(BPX1OPN) when the file system is recovered. (The BPX1CLO and BPX1OPN
callable services are discussed in z/OS UNIX System Services Programming:
Assembler Callable Services Reference.)
For file systems that are mounted read-only, specific I/O operations that were in
progress at the time the file system owner failed may need to be submitted again.
Otherwise, the file system is usable.
In some situations, even though a file system is mounted with the –a yes option,
ownership of the file system may not be immediately moved to another system.
This may occur, for example, when a physical I/O path from another system to the
volume where the file system resides is not available. As a result, the file system
becomes ″unowned″ (the system will issue message BPXF213E when this occurs).
This is true if the file system is mounted either read/write or read-only. The file
system still exists in the file system hierarchy so that any dependent file systems
that are owned by another system are still usable.
However, all file operations for the unowned file system will fail until a new owner is
established. The shared file system support will continue to attempt recovery of –a
yes mounted file systems on all systems in the sysplex that are enabled for shared
file system. Should a subsequent recovery attempt succeed, the file system
transitions from the unowned to the active state.
Applications using files in unowned file systems will need to close (BPX1CLO)
those files and re-open (BPX1OPN) them after the file system is recovered.
File systems that are mounted with the –a no option will become unowned when
the file system owner exits the sysplex. The file system will remain unowned until
436 z/OS V1R9.0 UNIX System Services Command Reference