About file compression in InfoScale Operations Manager
The compression feature in Storage Foundation enables customers to use host-based compression to optimize existing primary storage. Enabling compression at the file system layer results in storage savings and avoids complex and expensive appliances typically associated with primary compression. Use cases for compression include database archive logs and unstructured data.
Compression is performed without needing any application changes and with minimal overhead. Compression does not modify the file metadata, nor are inode numbers or file extensions changed. Compression is executed out-of-band, after the write.
In InfoScale Operations Manager, you set up file compression on a host at the file system (mount point) level by selecting directories for compression. You can compress directories on demand, and you can set up a schedule for running the compression process on the host. You can view a report of space saved by file compression. Once compression is enabled, directories and files will begin to have a mix of compressed and uncompressed data blocks. This is managed automatically by the file system, and uncompressed data is compressed during the next scheduled sweep.
Following are more details on how file compression works:
-
Only user data is compressible, not VxFS metadata.
-
Compression is a property of a file, not a directory. If you compress all files in a directory, for example, any files that you later copy into that directory do not automatically get compressed as a result of being copied into the directory.
-
A compressed file is a file with compressed extents. Writes to the compressed file cause the affected extents to get uncompressed; the result can be files with both compressed and uncompressed extents.
-
After a file is compressed, the inode number does not change, and file descriptors that are opened before the compression are still valid after the compression.
File compression can have the following interactions with applications:
-
In general, applications notice no difference between compressed and uncompressed files, although reads and writes to compressed extents are slower than reads and writes to uncompressed extents. When an application reads a compressed file, the file system does not perform its usual readahead to avoid the CPU load that this can require. However, when reading from the primary fileset, the file system uncompresses an entire compression block (default 1 MB) and leaves these pages in the page cache. Thus, sequential reads of the file usually only incur an extra cost when crossing a compression block boundary. The situation is different when reading from a file in a Storage Checkpoint; in this case, nothing goes into the page cache beyond the data actually requested. For optimal read performance of a compressed file accessed through a Storage Checkpoint, the application should use a read size that matches the compression block size.
-
When writing to compressed extents, ensure that you have sufficient disk space and disk quota limits for the new uncompressed extents since the write uncompresses the extents. If you do not have sufficient disk space, the write can fail with the ENOSPC or EDQUOT error.
-
An application that reads data from a compressed file and then copies the file elsewhere, such as
tar,cpio,cp, orvi, does not preserve compression in the new data. The same is true of some backup programs. -
Backup programs that read file data through the name space do not notice that the file is compressed. The backup program receives uncompressed data, and the compression is lost.
More Information
Related information