Veritas Storage Foundation 5.0.1 Cluster File System Administrator's Guide Extracts for the HP Serviceguard Storage Management Suite on HP-UX 11i v3

Parallel I/O
Some distributed applications read and write to the same file concurrently from one or more
nodes in the cluster; for example, any distributed application where one thread appends to a file
and there are one or more threads reading from various regions in the file. Several
high-performance computing (HPC) applications can also benefit from this feature, where
concurrent I/O is performed on the same file. Applications do not require any changes to use
this parallel I/O feature.
Traditionally, the entire file is locked to perform I/O to a small region. To support parallel I/O,
CFS locks ranges in a file that correspond to an I/O request. Two I/O requests conflict, if at least
one is a write request and it’s I/O range overlaps the I/O range of the other I/O request.
The parallel I/O feature enables I/O to a file by multiple threads concurrently, as long as the
requests do not conflict. Threads issuing concurrent I/O requests can execute on the same node,
or on a different node in the cluster.
An I/O request that requires allocation is not executed concurrently with other I/O requests. Note
that when a writer is extending the file and readers are lagging behind, block allocation is not
necessarily done for each extending write.
If the file size can be predetermined, the file can be preallocated to avoid block allocations during
I/O. This improves the concurrency of applications performing parallel I/O to the file. Parallel
I/O also avoids unnecessary page cache flushes and invalidations using range locking, without
compromising the cache coherency across the cluster.
For applications that update the same file from multiple nodes, the -nomtime mount option
provides further concurrency. Modification and change times of the file are not synchronized
across the cluster, which eliminates the overhead of increased I/O and locking. The timestamp
seen for these files from a node may not have the time updates that happened in the last 60
seconds.
Cluster File System Backup Strategies
The same backup strategies used for standard VxFS can be used with CFS, because the APIs and
commands for accessing the namespace are the same. File system checkpoints provide an on-disk,
point-in-time copy of the file system. HP recommends file system checkpoints over file system
snapshots (described below) for obtaining a frozen image of the cluster file system, because the
performance characteristics of a checkpointed file system are better in certain I/O patterns.
NOTE: See the Veritas File System Administrator's Guide, HP-UX, 5.0.1 for a detailed explanation
and comparison of checkpoints and snapshots.
A file system snapshot is another method for obtaining a file system on-disk frozen image. The
frozen image is non-persistent, in contrast to the checkpoint feature. A snapshot can be accessed
as a read-only mounted file system to perform efficient online backups. Snapshots implement
“copy-on-write” semantics that incrementally copy data blocks when they are overwritten on
the “snapped” file system. Snapshots for cluster file systems extend the same copy-on-write
mechanism for the I/O originating from any cluster node.
Mounting a snapshot filesystem for backups increases the load on the system because of the
resources used to perform copy-on-writes and to read data blocks from the snapshot. In this
situation, cluster snapshots can be used to do off-host backups. Off-host backups reduce the load
of a backup application on the primary server. Overhead from remote snapshots is small when
compared to overall snapshot overhead. Therefore, running a backup application by mounting
a snapshot from a relatively less loaded node is beneficial to overall cluster performance.
About CFS 17