Storage Foundation 7.4.1 Administrator's Guide - Linux
- Section I. Introducing Storage Foundation
- Overview of Storage Foundation
- How Dynamic Multi-Pathing works
- How Veritas Volume Manager works
- How Veritas Volume Manager works with the operating system
- How Veritas Volume Manager handles storage management
- Volume layouts in Veritas Volume Manager
- Online relayout
- Volume resynchronization
- Dirty region logging
- Volume snapshots
- FastResync
- 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
- 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
- Creating volumes of a specific layout
- Customizing allocation behavior
- Creating and mounting VxFS file systems
- Creating a VxFS file system
- Mounting a VxFS file system
- tmplog mount option
- ioerror mount option
- largefiles and nolargefiles mount options
- Resizing a file system
- Monitoring free space
- Extent attributes
- Section III. Administering multi-pathing with DMP
- Administering Dynamic Multi-Pathing
- Discovering and configuring newly added disk devices
- About discovering disks and dynamically adding disk arrays
- How to administer the Device Discovery Layer
- Administering DMP using the vxdmpadm utility
- Gathering and displaying I/O statistics
- Specifying the I/O policy
- Discovering and configuring newly added disk devices
- Dynamic Reconfiguration of devices
- Reconfiguring a LUN online that is under DMP control using the Dynamic Reconfiguration tool
- Manually reconfiguring a LUN online that is under DMP control
- Managing devices
- Displaying disk information
- Changing the disk device naming scheme
- Adding and removing disks
- Event monitoring
- Administering Dynamic Multi-Pathing
- Section IV. Administering Storage Foundation
- Administering sites and remote mirrors
- About sites and remote mirrors
- Fire drill - testing the configuration
- Changing the site name
- Administering the Remote Mirror configuration
- 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
- Managing application I/O workloads using maximum IOPS settings
- Section VI. Using Point-in-time copies
- Understanding point-in-time copy methods
- 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
- Traditional third-mirror break-off snapshots
- Full-sized instant snapshots
- Creating instant snapshots
- Adding an instant snap DCO and DCO volume
- Controlling instant snapshot synchronization
- Creating instant snapshots
- Cascaded snapshots
- Adding a version 0 DCO and DCO volume
- Administering Storage Checkpoints
- Storage Checkpoint administration
- 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
- Veritas 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
- Features implemented using multi-volume file system (MVFS) support
- Adding a volume to and removing a volume from a multi-volume file system
- Volume encapsulation
- Load balancing
- Administering SmartTier
- About SmartTier
- Placement classes
- Administering placement policies
- File placement policy rules
- Multiple criteria in file placement policy rule statements
- Using SmartTier with solid state disks
- Sub-file relocation
- Administering hot-relocation
- How hot-relocation works
- Moving relocated subdisks
- Deduplicating data
- Compressing files
- About compressing files
- Use cases for compressing files
- Section IX. Administering storage
- Managing volumes and disk groups
- Rules for determining the default disk group
- Moving volumes or disks
- Monitoring and controlling tasks
- Performing online relayout
- Adding a mirror to a volume
- Managing disk groups
- Disk group versions
- Displaying disk group information
- Importing a disk group
- Moving disk groups between systems
- Importing a disk group containing hardware cloned disks
- Handling conflicting configuration copies
- Destroying a disk group
- Backing up and restoring disk group configuration data
- Managing plexes and subdisks
- Decommissioning storage
- Rootability
- Encapsulating a disk
- Rootability
- Sample supported root disk layouts for encapsulation
- Encapsulating and mirroring the root disk
- Administering an encapsulated boot disk
- Quotas
- Using Veritas File System quotas
- File Change Log
- Managing volumes and disk groups
- Section X. Reference
- Appendix A. Reverse path name lookup
- Appendix B. Tunable parameters
- Tuning the VxFS file system
- Methods to change Dynamic Multi-Pathing tunable parameters
- Tunable parameters for VxVM
- Methods to change Veritas Volume Manager tunable parameters
- Appendix C. Command reference
UNCOMPRESS statement
The UNCOMPRESS statement in a file placement policy rule specifies in-place file uncompression on multi-volume and single-volume file systems. The placement policy becomes assigned to the selected file, and allocation for the uncompressed extents is done from the tier specified in the <SOURCE> element of the <FROM> clause.
If a file is partially compressed, then the file can be picked only for in-place compression. After being compressed, the file will be uncompressed before being relocated in the next policy enforcement.
Note:
SmartTier does not schedule uncompression activity. If you did not integrate your Veritas InfoScale product with the Veritas Operations Manager (VOM), then you must automate uncompression activity by using techniques such as scheduling through cron jobs.
The following XML snippet illustrates the general form of the UNCOMPRESS statement:
<UNCOMPRESS> <FROM> <SOURCE> <CLASS> placement_class_name </CLASS> </SOURCE> <SOURCE> additional_placement_class_specifications </SOURCE> </FROM> <WHEN> uncompression_conditions </WHEN> </UNCOMPRESS>
A UNCOMPRESS statement contains the following clauses:
<FROM> | An optional clause that contains a list of placement classes from whose volumes designated files should be uncompressed if the files meet the conditions specified in the <WHEN> clause. No priority is associated with the ordering of placement classes listed in a <FROM> clause. If a file to which the rule applies is located on a volume in any specified placement class, the file is considered for uncompression. If a UNCOMPRESS statement contains a <FROM> clause, VxFS only considers files that reside on volumes in placement classes specified in the clause for uncompression. If no <FROM> clause is present, qualifying files are uncompressed regardless of where the files reside. |
<WHEN> | An optional clause that indicates the conditions under which files to which the rule applies should be uncompressed. Files that have been unaccessed or unmodified for a specified period, reached a certain size, or reached a specific I/O temperature or access temperature level may be uncompressed. If a UNCOMPRESS statement does not contain a <WHEN> clause, files to which the rule applies are uncompressed unconditionally. A <WHEN> clause may be included in a UNCOMPRESS statement to specify that files should be uncompressed only if any or all of four types of criteria are met. Files can be specified for uncompression if they satisfy one or more criteria. |
The following are the criteria that can be specified for the <WHEN> clause:
<ACCAGE> | This criterion is met when files are inactive for a designated period or during a designated period relative to the time at which the fsppadm enforce command was issued. |
<MODAGE> | This criterion is met when files are unmodified for a designated period or during a designated period relative to the time at which the fsppadm enforce command was issued. |
<SIZE> | This criterion is met when files exceed or drop below a designated size or fall within a designated size range. |
<IOTEMP> | This criterion is met when files exceed or drop below a designated I/O temperature, or fall within a designated I/O temperature range. A file's I/O temperature is a measure of the I/O activity against it during the period designated by the <PERIOD>element prior to the time at which the fsppadm enforce command was issued. |
<ACCESSTEMP> | This criterion is met when files exceed or drop below a specified average access temperature, or fall within a specified access temperature range. A file's access temperature is similar to its I/O temperature, except that access temperature is computed using the number of I/O requests to the file, rather than the number of bytes transferred. |
Note:
The use of <IOTEMP> and <ACCESSTEMP> for data placement on VxFS servers that are used as NFS servers may not be very effective due to NFS caching. NFS client side caching and the way that NFS works can result in I/O initiated from an NFS client not producing NFS server side I/O. As such, any temperature measurements in place on the server side will not correctly reflect the I/O behavior that is specified by the placement policy.
If the server is solely used as an NFS server, this problem can potentially be mitigated by suitably adjusting or lowering the temperature thresholds. However, adjusting the thresholds may not always create the desired effect. In addition, if the same mount point is used both as an NFS export as well as a local mount, the temperature-based placement decisions will not be very effective due to the NFS cache skew.
The following XML snippet illustrates the general form of the <WHEN> clause in a UNCOMPRESS statement:
<WHEN> <ACCAGE Units="units_value"> <MIN Flags="comparison_operator"> min_access_age</MIN> <MAX Flags="comparison_operator"> max_access_age</MAX> </ACCAGE> <MODAGE Units="units_value"> <MIN Flags="comparison_operator"> min_modification_age</MIN> <MAX Flags="comparison_operator"> max_modification_age</MAX> </MODAGE> <SIZE " Units="units_value"> <MIN Flags="comparison_operator"> min_size</MIN> <MAX Flags="comparison_operator"> max_size</MAX> </SIZE> <IOTEMP Type="read_write_preference" Prefer="temperature_preference"> <MIN Flags="comparison_operator"> min_I/O_temperature</MIN> <MAX Flags="comparison_operator"> max_I/O_temperature</MAX> <PERIOD Units="days_or_hours"> days_or_hours_of_interest </PERIOD> </IOTEMP> <ACCESSTEMP Type="read_write_preference" Prefer="temperature_preference"> <MIN Flags="comparison_operator"> min_access_temperature</MIN> <MAX Flags="comparison_operator"> max_access_temperature</MAX> <PERIOD Units="days_or_hours"> days_or_hours_of_interest </PERIOD> </ACCESSTEMP> </WHEN>
The access age (<ACCAGE>) element refers to the amount of time since a file was last accessed. VxFS computes access age by subtracting a file's time of last access, atime, from the time when the fsppadm enforce command was issued. The <MIN> and <MAX> XML elements in an <ACCAGE> clause, denote the minimum and maximum access age thresholds for uncompression, respectively. These elements are optional, but at least one must be included. Using the Units XML attribute, the <MIN> and <MAX> elements may be specified in the following units:
hours | Hours |
days | Days. A day is considered to be 24 hours prior to the time that the fsppadm enforce command was issued. |
Both the <MIN> and <MAX> elements require Flags attributes to direct their operation.
For <MIN>, the following Flags attributes values may be specified:
gt | The time of last access must be greater than the specified interval. |
eq | The time of last access must be equal to the specified interval. |
gteq | The time of last access must be greater than or equal to the specified interval. |
For <MAX>, the following Flags attributes values may be specified.
lt | The time of last access must be less than the specified interval. |
lteq | The time of last access must be less than or equal to the specified interval. |
Including a <MIN> element in a <WHEN> clause causes VxFS to uncompress files to which the rule applies that have been inactive for longer than the specified interval. Such a rule would typically be used to uncompress inactive files to less expensive storage tiers. Conversely, including <MAX> causes files accessed within the specified interval to be uncompressed. It would typically be used to move inactive files against which activity had recommenced to higher performance or more reliable storage. Including both <MIN> and <MAX> causes VxFS to uncompress files whose access age lies between the two.
The modification age uncompression criterion, <MODAGE>, is similar to access age, except that files' POSIX mtime values are used in computations. You would typically specify the <MODAGE> criterion to cause uncompression of recently modified files to higher performance or more reliable storage tiers in anticipation that the files would be accessed recurrently in the near future.
The file size uncompression criterion, <SIZE>, causes files to be uncompressed if the files are larger or smaller than the values specified in the <MIN> and <MAX> uncompression criteria, respectively, at the time that the fsppadm enforce command was issued. Specifying both criteria causes VxFS to schedule uncompression for files whose sizes lie between the two. Using the Units attribute, threshold file sizes may be specified in the following units:
bytes | Bytes |
KB | Kilobytes |
MB | Megabytes |
GB | Gigabytes |