|
|
United States-English | |
|
|
 |
|
VERITAS File System 3.5 (HP OnlineJFS/JFS 3.5) Administrator's Guide: HP-UX 11i v2 > Chapter 2 VxFS Performance: Creating,
Mounting, and Tuning File Systems
Choosing mount Command Options |
|
|
In addition to the standard mount mode (delaylog mode), VxFS provides blkclear, log, tmplog, and nodatainlog modes of operation. Caching behavior can be altered with the mincache option, and the behavior of O_SYNC and D_SYNC (see the fcntl(2) manual page) writes can be altered with the convosync option. The delaylog and tmplog modes can significantly improve 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 the mount_vxfs(1M) manual page. 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. The default logging mode is 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. 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. The logiosize=size option is provided to enhance the performance of storage devices that employ a read-modify-write feature. If you specify logiosize when you mount a file system, VxFS writes the intent log in at least size bytes to obtain the maximum performance from such devices. The values for size can be 1024, 2048, or 4096. Use the nodatainlog mode on systems with disks that do not support bad block revectoring. Usually, 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 metadata 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 is approximately 50 percent slower than a standard mode VxFS file system for synchronous writes. Other operations are not affected. 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 is approximately 10 percent slower than a standard mode VxFS file system, depending on the workload. The mincache mode has five suboptions:
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 the vxfsio(7) manual page 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. Because 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, you can use the mincache=tmpcache mode. 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 the mincache=tmpcache option is used, bad data can appear in a file that was being extended when a crash occurred.
The convosync (convert osync) mode has five suboptions:
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 the open(2), fcntl(2), and vxfsio(7) manual pages for more information on O_SYNC.
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.
Sets the policy for handling I/O errors on a mounted file system. I/O errors can occur while reading or writing file data, or while reading or writing metadata. The file system can respond to these I/O errors either by halting or by gradually degrading. The ioerror option provides four policies that determine how the file system responds to the various errors. All four policies limit data corruption, either by stopping the file system or by marking a corrupted inode as bad. The four policies are disable, nodisable, wdisable, and mwdisable If disable is selected, VxFS disables the file system after detecting any I/O error. You must then unmount the file system and correct the condition causing the I/O error. After the problem is repaired, run fsck and mount the file system again. In most cases, replay fsck is sufficient to repair the file system. A full fsck is required only in cases of structural damage to the file system’s metadata. Select disable in environments where the underlying storage is redundant, such as RAID-5 or mirrored disks. If nodisable is selected, when VxFS detects an I/O error, it sets the appropriate error flags to contain the error, but continues running. Note that the “degraded” condition indicates possible data or metadata corruption, not the overall performance of the file system. For file data read and write errors, VxFS sets the VX_DATAIOERR flag in the superblock. For metadata read errors, VxFS sets the VX_FULLFSCK flag in the superblock. For metadata write errors, VxFS sets the VX_FULLFSCK and VX_METAIOERR flags in the superblock and may mark associated metadata as bad on disk. VxFS then prints the appropriate error messages to the console (see Appendix B “Kernel Messages” for information on actions to take for specific errors). You should stop the file system as soon as possible and repair the condition causing the I/O error. After the problem is repaired, run fsck and mount the file system again. Select nodisable if you want to implement the policy that most closely resembles the previous VxFS error handling policy. If wdisable (write disable) or mwdisable (metadata-write disable) is selected, the file system is disabled or degraded, depending on the type of error encountered. Select wdisable or mwdisable for environments where read errors are more likely to persist than write errors, such as when using non-redundant storage. mwdisable is the default ioerror mount option for local mounts. See the mount_vxfs(1M) manual page for more information. VxFS supports files up to two terabytes in size.
You can create a file system with large file capability by entering the following command:
Specifying largefiles sets the largefiles flag, which allows the file system to hold files up to two terabytes in size. Conversely, the default nolargefiles option clears the flag and prevents large files from being created:
Specifying the tranflush option is recommended when VxFS is used as the default boot file system (/stand). When tranflush is enabled, all metadata updates for that file system are both logged and flushed to disk. This greatly reduces the possibility of data and metadata inconsistency that can exist on a dirty file system before running a file system check (the fsck command). Using the tranflush option for non-boot file systems is not required, because fsck can be run on such file systems if they are not clean. Boot file systems require using tranflush to reduce data or metadata inconsistencies when the bootloader code accesses this file system after a crash (the bootloader code must access the boot file system to select the kernel to boot before fsck can be run). Because the tranflush option impairs file system performance due to the flushing operations, use it only for the /stand file system. The tranflush option automatically enables the blkclear and log options. It is advisable to specify the mincache=dsync mount option with tranflush. The tmplog, delaylog, and datainlog mount options do not operate with tranflush. The tranflush option must be explicitly specified when remounting the file system. The tranflush option does not operate on read-only file systems or cluster file systems. If a mount succeeds and nolargefiles is specified, the file system cannot contain or create any large files. If a mount succeeds and largefiles is specified, the file system may contain and create large files. The mount command fails if the specified largefiles|nolargefiles option does not match the on-disk flag. The mount command defaults to match the current setting of the on-disk flag if specified without the largefiles or nolargefiles option, so it’s best not to specify either option. After a file system is mounted, you can use the fsadm utility to change the large files option. You can determine the current status of the largefiles flag using the fsadm command:
You can switch capabilities on a mounted file system using the fsadm command:
You can also switch capabilities on an unmounted file system:
You cannot change a file system to nolargefiles if it holds large files. See the mount_vxfs(1M), fsadm_vxfs(1M), and mkfs_vxfs(1M) manual pages. Although mount options can be combined arbitrarily, some combinations do not make sense. The following examples provide some common and reasonable mount option combinations.
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.
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.
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 |
|
|
|
|
|
|||||||||||||||
|
|||||||||||||||
