InfoScale™ 9.0 Storage Foundation Administrator's Guide - Linux
- Section I. Introducing Storage Foundation
- Overview of Storage Foundation
- How Dynamic Multi-Pathing works
- How Volume Manager works
- How Volume Manager works with the operating system
- How Volume Manager handles storage management
- Volume layouts in Veritas Volume Manager
- Online relayout
- Volume resynchronization
- Hot-relocation
- Dirty region logging
- Volume snapshots
- Support for atomic writes
- FastResync
- Volume sets
- How VxVM handles hardware clones or snapshots
- Volume encryption
- How Veritas File System works
- Section II. Provisioning storage
- Provisioning new storage
- Advanced allocation methods for configuring storage
- Customizing allocation behavior
- Setting default values for vxassist
- Using rules to make volume allocation more efficient
- Understanding persistent attributes
- Customizing disk classes for allocation
- Specifying allocation constraints for vxassist operations with the use clause and the require clause
- Management of the use and require type of persistent attributes
- Creating volumes of a specific layout
- Creating a volume on specific disks
- Creating volumes on specific media types
- Configuring a Key Management Server
- Creating encrypted volumes
- Changing the KEK using the re-key operation
- Viewing encrypted volumes
- Changing the encryption password
- Enabling or disabling deletion of KEKs along with encrypted objects
- Specifying ordered allocation of storage to volumes
- Site-based allocation
- Changing the read policy for mirrored volumes
- Customizing allocation behavior
- Creating and mounting VxFS file systems
- Creating a VxFS file system
- Converting a file system to VxFS
- Mounting a VxFS file system
- log mount option
- delaylog mount option
- tmplog mount option
- logiosize mount option
- nodatainlog mount option
- blkclear mount option
- mincache mount option
- convosync mount option
- ioerror mount option
- largefiles and nolargefiles mount options
- cio mount option
- mntlock mount option
- ckptautomnt mount option
- Combining mount command options
- Unmounting a file system
- Resizing a file system
- Displaying information on mounted file systems
- Identifying file system types
- Monitoring free space
- Extent attributes
- Section III. Administering multi-pathing with DMP
- Administering Dynamic Multi-Pathing
- Discovering and configuring newly added disk devices
- Partial device discovery
- About discovering disks and dynamically adding disk arrays
- About third-party driver coexistence
- How to administer the Device Discovery Layer
- Listing all the devices including iSCSI
- Listing all the Host Bus Adapters including iSCSI
- Listing the ports configured on a Host Bus Adapter
- Listing the targets configured from a Host Bus Adapter or a port
- Listing the devices configured from a Host Bus Adapter and target
- Getting or setting the iSCSI operational parameters
- Listing all supported disk arrays
- Displaying details about an Array Support Library
- Excluding support for a disk array library
- Re-including support for an excluded disk array library
- Listing excluded disk arrays
- Listing disks claimed in the DISKS category
- Adding unsupported disk arrays to the DISKS category
- Removing disks from the DISKS category
- Foreign devices
- Making devices invisible to VxVM
- Making devices visible to VxVM
- About enabling and disabling I/O for controllers and storage processors
- About displaying DMP database information
- Displaying the paths to a disk
- Administering DMP using the vxdmpadm utility
- Retrieving information about a DMP node
- Displaying consolidated information about the DMP nodes
- Displaying the members of a LUN group
- Displaying paths controlled by a DMP node, controller, enclosure, or array port
- Displaying information about controllers
- Displaying information about enclosures
- Displaying information about array ports
- Displaying information about devices controlled by third-party drivers
- Displaying extended device attributes
- Suppressing or including devices from VxVM control
- Gathering and displaying I/O statistics
- Setting the attributes of the paths to an enclosure
- Displaying the redundancy level of a device or enclosure
- Specifying the minimum number of active paths
- Displaying the I/O policy
- Specifying the I/O policy
- Disabling I/O for paths, controllers, array ports, or DMP nodes
- Enabling I/O for paths, controllers, array ports, or DMP nodes
- Renaming an enclosure
- Configuring the response to I/O failures
- Configuring the I/O throttling mechanism
- Configuring Low Impact Path Probing (LIPP)
- Configuring Subpaths Failover Groups (SFG)
- Displaying recovery option values
- Configuring DMP path restoration policies
- Stopping the DMP path restoration thread
- Displaying the status of the DMP path restoration thread
- Configuring Array Policy Modules
- Configuring latency threshold tunable for metro/geo array
- Discovering and configuring newly added disk devices
- Dynamic Reconfiguration of devices
- About online dynamic reconfiguration
- Reconfiguring a LUN online that is under DMP control using the Dynamic Reconfiguration tool
- Manually reconfiguring a LUN online that is under DMP control
- Overview of manually reconfiguring a LUN
- Manually removing LUNs dynamically from an existing target ID
- Manually adding new LUNs dynamically to a new target ID
- About detecting target ID reuse if the operating system device tree is not cleaned up
- Scanning an operating system device tree after adding or removing LUNs
- Manually cleaning up the operating system device tree after removing LUNs
- Changing the characteristics of a LUN from the array side
- Upgrading the array controller firmware online
- Reformatting NVMe devices manually
- Managing devices
- Displaying disk information
- Changing the disk device naming scheme
- About disk installation and formatting
- Adding and removing disks
- Renaming a disk
- Event monitoring
- Administering Dynamic Multi-Pathing
- Section IV. Administering Storage Foundation
- Administering sites and remote mirrors
- About sites and remote mirrors
- Making an existing disk group site consistent
- Configuring a new disk group as a Remote Mirror configuration
- Fire drill - testing the configuration
- Changing the site name
- Administering the Remote Mirror configuration
- Examples of storage allocation by specifying sites
- Displaying site information
- Failure and recovery scenarios
- Administering sites and remote mirrors
- Section V. Optimizing I/O performance
- Veritas File System I/O
- Veritas Volume Manager I/O
- Veritas Volume Manager throttling of administrative I/O
- Managing application I/O workloads using maximum IOPS settings
- About application volume groups
- Creating application volume groups
- Viewing the list of application volume groups
- Setting the maximum IOPS threshold on application volume groups
- Viewing the IOPS statistics for application volume groups
- Removing the maximum IOPS setting from application volume groups
- Adding volumes to an application volume group
- Removing volumes from an application volume group
- Removing an application volume group
- Section VI. Using Point-in-time copies
- Understanding point-in-time copy methods
- About point-in-time copies
- When to use point-in-time copies
- About Storage Foundation point-in-time copy technologies
- Volume-level snapshots
- Storage Checkpoints
- About FileSnaps
- About snapshot file systems
- Administering volume snapshots
- About volume snapshots
- Traditional third-mirror break-off snapshots
- Full-sized instant snapshots
- Creating instant snapshots
- Adding an instant snap DCO and DCO volume
- Creating and managing space-optimized instant snapshots
- Creating and managing full-sized instant snapshots
- Creating and managing third-mirror break-off snapshots
- Creating and managing linked break-off snapshot volumes
- Creating multiple instant snapshots
- Creating instant snapshots of volume sets
- Adding snapshot mirrors to a volume
- Removing a snapshot mirror
- Removing a linked break-off snapshot volume
- Adding a snapshot to a cascaded snapshot hierarchy
- Refreshing an instant space-optimized snapshot
- Reattaching an instant full-sized or plex break-off snapshot
- Reattaching a linked break-off snapshot volume
- Restoring a volume from an instant space-optimized snapshot
- Dissociating an instant snapshot
- Removing an instant snapshot
- Splitting an instant snapshot hierarchy
- Displaying instant snapshot information
- Controlling instant snapshot synchronization
- Listing the snapshots created on a cache
- Tuning the autogrow attributes of a cache
- Monitoring and displaying cache usage
- Growing and shrinking a cache
- Removing a cache
- Creating instant snapshots
- Linked break-off snapshots
- Cascaded snapshots
- Creating multiple snapshots
- Restoring the original volume from a snapshot
- Adding a version 0 DCO and DCO volume
- Administering Storage Checkpoints
- About Storage Checkpoints
- Storage Checkpoint administration
- Storage Checkpoint space management considerations
- Restoring from a Storage Checkpoint
- Storage Checkpoint quotas
- Administering FileSnaps
- Administering snapshot file systems
- Understanding point-in-time copy methods
- Section VII. Optimizing storage with Storage Foundation
- Understanding storage optimization solutions in Storage Foundation
- Migrating data from thick storage to thin storage
- Maintaining Thin Storage with Thin Reclamation
- Reclamation of storage on thin reclamation arrays
- Identifying thin and thin reclamation LUNs
- Displaying VxFS file system usage on thin reclamation LUNs
- Reclaiming space on a file system
- Reclaiming space on a disk, disk group, or enclosure
- About the reclamation log file
- Monitoring Thin Reclamation using the vxtask command
- Configuring automatic reclamation
- InfoScale 4K sector device support solution
- Section VIII. Maximizing storage utilization
- Understanding storage tiering with SmartTier
- Creating and administering volume sets
- Multi-volume file systems
- About multi-volume file systems
- About volume types
- Features implemented using multi-volume file system (MVFS) support
- Creating multi-volume file systems
- Converting a single volume file system to a multi-volume file system
- Adding a volume to and removing a volume from a multi-volume file system
- Volume encapsulation
- Reporting file extents
- Load balancing
- Converting a multi-volume file system to a single volume file system
- Administering SmartTier
- About SmartTier
- Supported SmartTier document type definitions
- Placement classes
- Administering placement policies
- File placement policy grammar
- File placement policy rules
- Calculating I/O temperature and access temperature
- Multiple criteria in file placement policy rule statements
- Multiple file selection criteria in SELECT statement clauses
- Multiple placement classes in <ON> clauses of CREATE statements and in <TO> clauses of RELOCATE statements
- Multiple placement classes in <FROM> clauses of RELOCATE and DELETE statements
- Multiple conditions in <WHEN> clauses of RELOCATE and DELETE statements
- File placement policy rule and statement ordering
- File placement policies and extending files
- Using SmartTier with solid state disks
- Sub-file relocation
- Administering hot-relocation
- About hot-relocation
- How hot-relocation works
- Configuring a system for hot-relocation
- Displaying spare disk information
- Marking a disk as a hot-relocation spare
- Removing a disk from use as a hot-relocation spare
- Excluding a disk from hot-relocation use
- Making a disk available for hot-relocation use
- Configuring hot-relocation to use only spare disks
- Moving relocated subdisks
- Modifying the behavior of hot-relocation
- Compressing files
- About compressing files
- Compressing files with the vxcompress command
- Interaction of compressed files and other commands
- Interaction of compressed files and other features
- Interaction of compressed files and applications
- Use cases for compressing files
- Section IX. Administering and protecting storage
- Managing volumes and disk groups
- Rules for determining the default disk group
- Moving volumes or disks
- Monitoring and controlling tasks
- Using vxnotify to monitor configuration changes
- Performing online relayout
- Adding a mirror to a volume
- Configuring SmartMove
- Removing a mirror
- Setting tags on volumes
- Encrypting existing volumes
- Managing disk groups
- Disk group versions
- Displaying disk group information
- Creating a disk group
- Removing a disk from a disk group
- Deporting a disk group
- Importing a disk group
- Handling of minor number conflicts
- Moving disk groups between systems
- Importing a disk group containing hardware cloned disks
- Setting up configuration database copies (metadata) for a disk group
- Renaming a disk group
- Handling conflicting configuration copies
- Disabling a disk group
- Destroying a disk group
- Backing up and restoring disk group configuration data
- Working with existing ISP disk groups
- Managing plexes and subdisks
- Decommissioning storage
- Rootability
- Root Disk Encapsulation (RDE) is not supported
- Encapsulating a disk
- Device name format changes in RHEL 7 environments after encapsulation
- Rootability
- Restrictions on using rootability with Linux
- Sample supported root disk layouts for encapsulation
- Example 1: supported root disk layouts for encapsulation
- Example 2: supported root disk layouts for encapsulation
- Example 3: supported root disk layouts for encapsulation
- Example 4: supported root disk layouts for encapsulation
- Sample unsupported root disk layouts for encapsulation
- Example 1: unsupported root disk layouts for encapsulation
- Example 2: unsupported root disk layouts for encapsulation
- Example 3: unsupported root disk layouts for encapsulation
- Example 4: unsupported root disk layouts for encapsulation
- Booting root volumes
- Boot-time volume restrictions
- Creating redundancy for the root disk
- Creating an archived back-up root disk for disaster recovery
- Encapsulating and mirroring the root disk
- Upgrading the kernel on a root encapsulated system
- Administering an encapsulated boot disk
- Unencapsulating the root disk
- Quotas
- About Veritas File System quota limits
- About quota files on Veritas File System
- About Veritas File System quota commands
- About quota checking with Veritas File System
- Using Veritas File System quotas
- Turning on Veritas File System quotas
- Turning on Veritas File System quotas at mount time
- Editing Veritas File System quotas
- Modifying Veritas File System quota time limits
- Viewing Veritas File System disk quotas and usage
- Displaying blocks owned by users or groups
- Turning off Veritas File System quotas
- Support for 64-bit Quotas
- File Change Log
- Support for protection against ransomware
- About support for protection against ransomware
- Write Once, Read Many (WORM) storage
- Secure clock
- Audit logging
- Non-modifiable storage checkpoints
- Post-upgrade tasks to enable the use of non-modifiable checkpoints
- Creating non-modifiable checkpoints
- Setting retention periods for non-modifiable checkpoints
- Making an existing checkpoint non-modifiable
- Deletion of non-modifiable checkpoints
- Compatibility of WORM flag with relevant checkpoint operations
- Restrictions and limitations on the promote operation for checkpoints
- Restrictions and limitations on the mount operations
- Soft WORM storage
- About the secure configuration file
- Secure file system
- Secure file system for Oracle Single Instance
- Secure file system for PostgreSQL database
- Prerequisites for configuring SecureFS for PostgreSQL
- Enabling PostgreSQL for SecureFS and Single-Click Recovery
- SecureFS authentication methods for PostgreSQL
- PostgreSQL configuration reload and restart requirements
- Configure SecureFS for PostgreSQL using CLI
- Recovering PostgreSQL data
- PostgreSQL SecureFS configuration logs
- SecureFS limitations for PostgreSQL
- Managing volumes and disk groups
- Section X. Reference
- Appendix A. Reverse path name lookup
- Appendix B. Tunable parameters
- About tuning Storage Foundation
- Tuning the VxFS file system
- DMP tunable parameters
- Methods to change Dynamic Multi-Pathing tunable parameters
- Tunable parameters for VxVM
- Methods to change Veritas Volume Manager tunable parameters
- Appendix C. Command reference
- Appendix D. InfoScale event logging
Tunable parameters for core VxVM
Table: Kernel tunable parameters for core VxVM lists the kernel tunable parameters for VxVM.
You can tune the parameters using the vxtune command or the operating system method, unless otherwise noted.
Table: Kernel tunable parameters for core VxVM
Parameter | Description |
|---|---|
The interval at which utilities performing recoveries or resynchronization operations load the current offset into the kernel as a checkpoint. A system failure during such operations does not require a full recovery, but can continue from the last reached checkpoint. The default value is 20480 sectors (10MB). Increasing this size reduces the overhead of checkpoints on recovery operations at the expense of additional recovery following a system failure during a recovery. | |
The count in clock ticks for which utilities pause if they have been directed to reduce the frequency of issuing I/O requests, but have not been given a specific delay time. This tunable is used by utilities performing operations such as resynchronizing mirrors or rebuilding RAID-5 columns. The default value is 50 ticks. Increasing this value results in slower recovery operations and consequently lower system impact while recoveries are being performed. | |
vol_max_adminio_poolsz | The maximum size of the memory pool that is used for administrative I/O operations. VxVM uses this pool when throttling administrative I/O. The default value is 128MB. The maximum size must not be greater than the value of the voliomem_maxpool_sz parameter. |
This parameter cannot be tuned with the vxtune command. The maximum number of volumes that can be created on the system. The minimum permitted value is 1. The maximum permitted value is the maximum number of minor numbers representable on the system. The default value is 65534. | |
The maximum size of logical I/O operations that can be performed without breaking up the request. I/O requests to VxVM that are larger than this value are broken up and performed synchronously. Physical I/O requests are broken up based on the capabilities of the disk device and are unaffected by changes to this maximum logical request limit. The default value is 2048 sectors (1 MB). The value of voliomem_maxpool_sz must be at least 10 times greater than the value of vol_maxio. If DRL sequential logging is configured, the value of voldrl_min_regionsz must be set to at least half the value of vol_maxio. The maximum limit for vol_maxio is 20% of the smaller of physical memory or kernel virtual memory. It is inadvisable to go over this limit. | |
The maximum size of data that can be passed into VxVM via an ioctl call. Increasing this limit allows larger operations to be performed. Decreasing the limit is not generally recommended, because some utilities depend upon performing operations of a certain size and can fail unexpectedly if they issue oversized ioctl requests. | |
The number of I/O operations that the vxconfigd daemon is permitted to request from the kernel in a single VOL_VOLDIO_READ per VOL_VOLDIO_WRITE ioctl call. The default value is 256. This value should not be changed. | |
The maximum size of an I/O request that can be issued by an ioctl call. Although the ioctl request itself can be small, it can request that a large I/O request be performed. This tunable limits the size of these I/O requests. If necessary, a request that exceeds this value can be failed, or the request can be broken up and performed synchronously. The default value is 2048 sectors. Raising this limit can cause difficulties if the size of an I/O request causes the process to take more memory or kernel virtual mapping space than exists and thus deadlock. The maximum limit for this tunable is 20% of the smaller of physical memory or kernel virtual memory. It is inadvisable to go over this limit, because deadlock is likely to occur. If stripes are larger than the value of this tunable, full stripe I/O requests are broken up, which prevents full-stripe read/writes. This throttles the volume I/O throughput for sequential I/O or larger I/O requests. This tunable limits the size of an I/O request at a higher level in VxVM than the level of an individual disk. For example, for an 8 by 64KB stripe, a value of 256KB only allows I/O requests that use half the disks in the stripe; thus, it cuts potential throughput in half. If you have more columns or you have used a larger interleave factor, then your relative performance is worse. This tunable must be set, as a minimum, to the size of your largest stripe (RAID-0 or RAID-5). | |
Enables or disables the I/O stat collection for Veritas Volume manager objects. The default value is 1, since this functionality is enabled by default. | |
The maximum number of subdisks that can be attached to a single plex. The default value of this tunable is 4096. | |
The granularity of memory chunks used by VxVM when allocating or releasing system memory. A larger granularity reduces CPU overhead by allowing VxVM to retain hold of a larger amount of memory. The value of this tunable parameter depends on the page size of the system. You cannot specify a value larger than the default value. If you change the value, VxVM aligns the values to the page size when the system reboots. The default value is 32 KB for 512 Byte page size. | |
The maximum memory requested from the system by VxVM for internal purposes. This tunable has a direct impact on the performance of VxVM as it prevents one I/O operation from using all the memory in the system. VxVM allocates two pools that can grow up to this size, one for RAID-5 and one for mirrored volumes. Additional pools are allocated if instant (Copy On Write) snapshots are present. A write request to a RAID-5 volume that is greater than one fourth of the pool size is broken up and performed in chunks of one tenth of the pool size. A write request to a mirrored volume that is greater than the pool size is broken up and performed in chunks of the pool size. The default value is 134217728 (128MB). The value of voliomem_maxpool_sz must be greater than the value of volraid_minpool_size. The value of voliomem_maxpool_sz must be at least 10 times greater than the value of vol_maxio. | |
The default size of the buffer maintained for error tracing events. This buffer is allocated at driver load time and is not adjustable for size while VxVM is running. The default value is 16384 bytes (16KB). Increasing this buffer can provide storage for more error events at the expense of system memory. Decreasing the size of the buffer can result in an error not being detected via the tracing device. Applications that depend on error tracing to perform some responsive action are dependent on this buffer. | |
The default size for the creation of a tracing buffer in the absence of any other specification of desired kernel buffer size as part of the trace ioctl. The default value is 8192 bytes (8 KB). If trace data is often being lost due to this buffer size being too small, then this value can be increased. | |
The upper limit to the size of memory that can be used for storing tracing buffers in the kernel. Tracing buffers are used by the VxVM kernel to store the tracing event records. As trace buffers are requested to be stored in the kernel, the memory for them is drawn from this pool. Increasing this size can allow additional tracing to be performed at the expense of system memory usage. Setting this value to a size greater than can readily be accommodated on the system is inadvisable. The default value is 131072 bytes (128 KB). | |
The maximum buffer size that can be used for a single trace buffer. Requests of a buffer larger than this size are silently truncated to this size. A request for a maximal buffer size from the tracing interface results (subject to limits of usage) in a buffer of this size. The default value is 65536 bytes (64 KB). Increasing this buffer can provide for larger traces to be taken without loss for very heavily used volumes. Do not increase this value above the value for the voliot_iobuf_limit tunable value. | |
The maximum number of tracing channels that can be open simultaneously. Tracing channels are clone entry points into the tracing device driver. Each vxtrace process running on a system consumes a single trace channel. The default number of channels is 32. The allocation of each channel takes up approximately 20 bytes even when the channel is not in use. | |
volraid_minpool_size | This parameter cannot be tuned with the vxtune command. The initial amount of memory that is requested from the system by VxVM for RAID-5 operations. The maximum size of this memory pool is limited by the value of voliomem_maxpool_sz. The default value is 8192 sectors (4MB). |
The maximum number of transient reconstruct operations that can be performed in parallel for RAID-5. A transient reconstruct operation is one that occurs on a non-degraded RAID-5 volume that has not been predicted. Limiting the number of these operations that can occur simultaneously removes the possibility of flooding the system with many reconstruct operations, and so reduces the risk of causing memory starvation. The default value is 1. Increasing this size improves the initial performance on the system when a failure first occurs and before a detach of a failing object is performed, but can lead to memory starvation. | |
autostartvolumes | Turns on or off the automatic volume recovery. When set to on, VxVM automatically recovers and starts disabled volumes when you import, join, move, or split a disk group. When set to off, turns off this behavior. The default value is on. |
delete_stale_kms_keys | Enables or disables the deletion of the associated key when an encrypted object is deleted. The default value is 0 (zero). See KEK deletion alongside encrypted objects. See Enabling or disabling deletion of KEKs along with encrypted objects. |
fssmartmovethreshold | The threshold for an individual file system, in percentage full. After this threshold is reached, the SmartMove feature is not used. The default value is 100. |
reclaim_on_delete_start_time | The time of day when the reclamation begins on a thin LUN, after a volume using that LUN is deleted. Specified in 24 hour time (HH:MM). The default value is 22:10. |
reclaim_on_delete_wait_period | The number of days to wait before starting to reclaim space on a thin LUN, after a volume using that LUN is deleted. Specified as an integer from −1 to 366, where −1 specifies immediately and 366 specifies never. The default value is 1. |
usefssmartmove | The state of the SmartMove feature. Valid values are:
The default value is all. |