In addition to the standard mount mode (log mode), VxFS provides blkclear, delaylog, tmplog, nolog, and nodatainlog modes of operation. Caching behavior can be altered
with the mincache option, and the behavior of O_SYNC and D_SYNC (see fcntl(2)) writes can be altered with the convosync option.
The delaylog and tmplog modes are capable of significantly improving performance.
The improvement over log mode is typically about 15 to 20 percent with delaylog; with tmplog, the improvement is even higher. Performance improvement
varies, depending on the operations being performed and the workload.
Read/write intensive loads should show less improvement, while file
system structure intensive loads (such as mkdir, create, and rename) may show over 100 percent improvement. The best
way to select a mode is to test representative system loads against
the logging modes and compare the performance results.
Most of the modes can be used in combination. For example,
a desktop machine might use both the blkclear and mincache=closesync modes.
Additional information on mount options can be found in mount_vxfs(1M).
log |
 |
The default logging mode is log. With log mode, VxFS guarantees that all structural changes
to the file system have been logged on disk when the system call
returns. If a system failure occurs, fsck replays recent changes so that they will not be
lost.
delaylog |
|
In delaylog mode, some system calls return before the intent
log is written. This logging delay improves the performance of the
system, but some changes are not guaranteed until a short time after
the system call returns, when the intent log is written. If a system
failure occurs, recent changes may be lost. This mode approximates
traditional UNIX guarantees for correctness in case of system failures.
Fast file system recovery works with this mode.
tmplog |
|
In tmplog mode, intent logging is almost always delayed.
This greatly improves performance, but recent changes may disappear
if the system crashes. This mode is only recommended for temporary
file systems. Fast file system recovery works with this mode.
nolog |
|
Same as tmplog.
nodatainlog |
|
The nodatainlog mode should be used on systems with disks that
do not support bad block revectoring. Normally, a VxFS file system
uses the intent log for synchronous writes. The inode update and
the data are both logged in the transaction, so a synchronous write
only requires one disk write instead of two. When the synchronous
write returns to the application, the file system has told the application
that the data is already written. If a disk error causes the data
update to fail, then the file must be marked bad and the entire
file is lost.
If a disk supports bad block revectoring, then a failure on
the data update is unlikely, so logging synchronous writes should
be allowed. If the disk does not support bad block revectoring,
then a failure is more likely, so the nodatainlog mode should be used.
A nodatainlog mode file system should be approximately 50 percent slower
than a standard mode VxFS file system for synchronous writes. Other
operations are not affected.
blkclear |
|
The blkclear mode is used in increased data security environments. The blkclear mode guarantees that uninitialized storage never
appears in files. The increased integrity is provided by clearing
extents on disk when they are allocated within a file. Extending
writes are not affected by this mode. A blkclear mode file system should be approximately 10 percent
slower than a standard mode VxFS file system, depending on the workload.
mincache |
|
The mincache mode has five suboptions:
|
| |
|
 | NOTE: The mincache=direct, mincache=dsync, mincache=unbuffered, and mincache=tmpcache modes are only available with the HP OnLineJFS product. |
|
| |
|
The mincache=closesync mode is useful in desktop environments where users
are likely to shut off the power on the machine without halting
it first. In this mode, any changes to the file are flushed to disk when
the file is closed.
To improve performance, most file systems do not synchronously
update data and inode changes to disk. If the system crashes, files
that have been updated within the past minute are in danger of losing
data. With the mincache=closesync mode, if the system crashes or is switched off, only
files that are currently open can lose data. A mincache=closesync mode file system should be approximately 15 percent
slower than a standard mode VxFS file system, depending on the workload.
The mincache=direct, mincache=unbuffered, and mincache=dsync modes are used in environments where applications
are experiencing reliability problems caused by the kernel buffering
of I/O and delayed flushing of non-synchronous I/O. The mincache=direct and mincache=unbuffered modes guarantee that all non-synchronous I/O requests
to files will be handled as if the VX_DIRECT or VX_UNBUFFERED caching advisories had been specified. The mincache=dsync mode guarantees that all non-synchronous I/O requests
to files will be handled as if the VX_DSYNC caching advisory had been specified. Refer to vxfsio(7) for explanations of VX_DIRECT, VX_UNBUFFERED, and VX_DSYNC. The mincache=direct, mincache=unbuffered, and mincache=dsync modes also flush file data on close as mincache=closesync does.
Since the mincache=direct, mincache=unbuffered, and mincache=dsync modes change non-synchronous I/O to synchronous
I/O, there can be a substantial degradation in throughput for small
to medium size files for most applications. Since the VX_DIRECT and VX_UNBUFFERED advisories do not allow any caching of data, applications that
would normally benefit from caching for reads will usually experience
less degradation with the mincache=dsync mode. mincache=direct and mincache=unbuffered require significantly less CPU time than buffered
I/O.
If performance is more important than data integrity, the mincache=tmpcache mode may be used. The mincache=tmpcache mode disables special delayed extending write
handling, trading off less integrity for better performance. Unlike
the other mincache modes, tmpcache does not flush the file to disk when it is closed.
When this option is used, garbage may appear in a file that was
being extended when a crash occurred.
convosync |
|
|
| |
|
| NOTE: Use of the convosync=dsync option violates POSIX guarantees for synchronous
I/O. |
|
| |
|
The "convert osync" (convosync) mode has five suboptions: convosync=closesync, convosync=direct, convosync=dsync, convosync=unbuffered, and convosync=delay.
|
| |
|
| NOTE: The convosync option is available only with the HP OnLineJFS
product. |
|
| |
|
The convosync=closesync mode converts synchronous and data synchronous
writes to non-synchronous writes and flushes the changes to the
file to disk when the file is closed.
The convosync=delay mode causes synchronous and data synchronous writes
to be delayed rather than to take effect immediately. No special action
is performed when closing a file. This option effectively cancels any
data integrity guarantees normally provided by opening a file with O_SYNC. See open(2), fcntl(2), and vxfsio(7) for more information on O_SYNC.
|
| |
|
 | CAUTION: Extreme care should be taken when using the convosync=closesync or convosync=delay mode because they actually change synchronous
I/O into non-synchronous I/O. This may cause applications that use synchronous
I/O for data reliability to fail if the system crashes and synchronously
written data is lost. |
|
| |
|
The convosync=direct and convosync=unbuffered mode convert synchronous and data synchronous
reads and writes to direct reads and writes.
The convosync=dsync mode converts synchronous writes to data synchronous
writes.
As with closesync, the direct, unbuffered, and dsync modes flush changes to the file to disk when it
is closed. These modes can be used to speed up applications that
use synchronous I/O. Many applications that are concerned with data
integrity specify the O_SYNC fcntl in order to write the file data synchronously.
However, this has the undesirable side effect of updating inode
times and therefore slowing down performance. The convosync=dsync, convosync=unbuffered, and convosync=direct modes alleviate this problem by allowing applications
to take advantage of synchronous writes without modifying inode
times as well.
|
| |
|
| NOTE: Before using convosync=dsync, convosync=unbuffered, or convosync=direct, make sure that all applications that use the
file system do not require synchronous inode time updates for O_SYNC writes. |
|
| |
|
Combining
mount Options |
|
Although mount options can be combined arbitrarily, some combinations do
not make sense. The following examples provide some common and reasonable mount option combinations.
Example 1 - Desktop File System
# mount -F vxfs -o log,mincache=closesync /dev/dsk/c1t3d0 /mnt |
This guarantees that when a file is closed, its data is synchronized
to disk and cannot be lost. Thus, once an application is exited
and its files are closed, no data will be lost even if the system
is immediately turned off.
Example 2 - Temporary File System
or Restoring from Backup
# mount -F vxfs -o tmplog,convosync=delay,mincache=tmpcache \
/dev/dsk/c1t3d0 /mnt |
This combination might be used for a temporary file system
where performance is more important than absolute data integrity.
Any O_SYNC writes are performed as delayed writes and delayed
extending writes are not handled specially (which could result in
a file that contains garbage if the system crashes at the wrong
time). Any file written 30 seconds or so before a crash may contain
garbage or be missing if this mount combination is in effect. However, such a file
system will do significantly less disk writes than a log file system, and should have significantly better
performance, depending on the application.
Example 3 - Data Synchronous Writes
# mount -F vxfs -o log,convosync=dsync /dev/dsk/c1t3d0 /mnt |
This combination would be used to improve the performance
of applications that perform O_SYNC writes, but only require data synchronous write
semantics. Their performance can be significantly improved if the
file system is mounted using convosync=dsync without any loss of data integrity.
Printable version
