With no options, vxtunefs will print the existing vxfs parameters for the specified file systems.
vxtunefs can work on a list of mount points specified on the command line or it can be used to process all the mounted file systems listed in the tunefstab file. The default tunefstab file is /etc/vx/tunefstab; this can be changed by using the VXTUNEFSTAB environment variable.
The vxtunefs command can be run at any time on a mounted file system and all parameter changes will take immediate effect. Parameters specified on the command line override any parameters listed in the tunefstab file.
If the file /etc/vx/tunefstab exists, then the vxfs specific mount command will invoke vxtunefs to set any parameters for the device from /etc/vx/tunefstab. If the file system is built on top of the VERITAS Volume Manager, then the vxfs specific mount command will interface with the Volume Manager to get default values for the tunables, so it is only necessary to specify tunables for Volume Manager devices if the the defaults are not acceptable.
Note that this tunable should be used carefully. If it is set too large, then writes will fail when they are unable to allocate extents of the indirect extent size to a file. In general, the fewer and the larger the files on a file system, the larger the default_indir_size can be set. This parameter should generally be set to some multiple of the read_pref_io parameter.
This tuneable is not applicable on version 3 or version 4 disk layouts.
On systems with large memories, the database cannot always use all of the memory as a cache. By enabling file system caching as a second level cache, performance may be improved.
If the database is performing sequential scans of tables, the scans may run faster by enabling file system caching so the file system will perform aggressive read-ahead on the files.
When the file system is following its default allocation policy for sequential writes to a file, it allocates an intial extent which is large enough for the first write to the file. When additional extents are allocated, they are progressively larger (the algorithm tries to double the size of the file with each new extent) so each extent can hold several writes worth of data. This is done to reduce the total number of extents in anticipation of continued sequential writes. When the file stops being written, any unused space is freed for other files to use.
Normally this allocation stops increasing the size of extents at 2048 blocks which prevents one file from holding too much unused space.
max_seqio_extent_size is measured in filesystem blocks.
VxFS determines, based on the first write to a new file, the size of the first extent to be allocated to the file. Normally the first extent is the smallest power of 2 that is larger than the size of the first write. If that power of 2 is less than 8KB, the first extent allocated is 8KB. After the initial extent, the file system increases the size of subsequent extents (see max_seqio_extent_size) with each allocation.
Since most applications write to files using a buffer size of 8KB or less, the increasing extents start doubling from a small initial extent. def_init_extent is used to change the default initial extent size to be larger, so the doubling policy will start from a much larger initial size and the file system won't allocate a set of small extents at the start of file.
This paramter should only be used on file systems that will have a very large average file size. On these file systems it will result in fewer extents per file and less fragmentation.
def_init_extent is measured in filesystem blocks.
The values for all the above parameters except read_nstream, write_nstream, qio_cache, and pref_strength can be specified in bytes, kilobytes, megabytes or sectors (512 bytes) by appending k, K, m, M, s, or S. There is no need for a suffix to be specified for the value in bytes.
If the file system is being used with the VERITAS Volume Manager, then it is advisable to let the parameters get set to default values based on the volume geometry.
If the file system is being used with a hardware disk array or another volume manager, then try to align the parameters to match the geometry of the logical disk. For disk striping and RAID-5 configurations, set read_pref_io to the stripe unit size or interleave factor and set read_nstream to be the number of columns. For disk striping configurations, set write_pref_io and write_nstream to the same values as read_pref_io and read_nstream, but for RAID-5 configurations set write_pref_io to the full stripe size and set write_nstream to 1.
An application that wishes to do efficient direct I/O or discovered direct I/O should issue read requests that are equal to the product of read_nstream multiplied by read_pref_io. Generally any multiple or factor of read_nstream multiplied by read_pref_io should be a good size for performance. For writing, the same rule of thumb applies to the write_pref_io and write_nstream parameters. When tuning a file system, the best thing to do is try out the tuning parameters under a real workload.
If an application is doing sequential I/O to large files, it should try to issue request larger than the discovered_direct_iosz. This will cause the I/O requests to be performed as discovered direct I/O requests which are unbuffered like direct I/O but do not require synchronous inode updates when extending the file. If the file is larger than will fit in the cache, then using unbuffered I/O will avoid throwing a lot of useful data out of the cache and it will avoid a lot of CPU overhead.
The value of vol_maxio is in sectors and it is stored as a 16 bit number so it can't be set larger than 65535. This line must be added to /etc/system after the "forceload: drv/vxio" line.
The value of vol_maxio determines the largest amount of memory that an I/O request can lock down, so it should not be set to more than about 20% of memory. For more information on setting Volume Manager parameters, see the VERITAS Volume Manager System Administrator's Guide.