InfoScale™ 9.0 SmartIO for Solid-State Drives Solutions Guide - Solaris
- Introducing SFHA Solutions SmartIO
- Using the SmartIO feature: use cases
- About SmartIO read caching for applications running on VxVM volumes
- About SmartIO read caching for applications running on VxFS file systems
- About SmartIO caching on SSD devices exported by FSS
- About SmartIO write-back caching for applications running on VxFS file systems
- About multiple SmartIO cache areas for read and write-back caching on VxFS file systems
- About SmartIO caching for Oracle databases on VxFS file systems
- Prerequisites and configuration for using the SmartIO plug-in for Oracle
- Setting default SmartIO caching policies for a database running on a VxFS file system
- Setting SmartIO caching policies for database objects
- Pinning and unpinning database objects
- Enabling and disabling caching for the database
- Listing cache policy details for the database
- Listing cache statistics for the database
- About SmartIO caching for databases on VxVM volumes
- Administering SmartIO
- Creating a cache area
- Displaying information about a cache area
- Enabling or disabling caching for a data object
- Adding a device to the cache area
- Pausing caching from a volume to a cache area
- Removing a device from the cache area
- Destroying a cache area
- Setting the attributes of the VxVM cache area
- Setting or changing the caching mode for a VxFS cache area
- Flushing dirty data from a writeback cache area
- Tuning the writeback caching
- Viewing the SmartIO cache statistics
- Troubleshooting and error handling
- Appendix A. Command reference
About SmartIO write-back caching for applications running on VxFS file systems
InfoScale Storage and InfoScale Enterprise supports write-back caching on solid-state drives (SSDs) for applications running on Veritas File System (VxFS) file systems. In this scenario, application reads and writes are satisfied from the cache whenever possible.
Note:
SmartIO write-back caching is not currently supported in SF Oracle RAC environments.
SmartIO provides write caching in the writeback mode. In writeback mode, an application write returns success after the data is written to the SmartIO cache, which is usually on an SSD. At a later time, SmartIO flushes the cache, which writes the dirty data to the disk. Write-back caching expects to improve the latencies of synchronous user data writes. Write order fidelity is not guaranteed while flushing the dirty data to the disk.
Write-back caching is superset of read caching. When write-back caching is enabled, read caching is implicitly enabled. Reads are satisfied from the cache if possible, and the file system transparently loads file data into the cache. Both read and write-back caching may be enabled for the same file at the same time.
The writeback caching mode gives good performance for writes, but also means that the disk copy may not always be up to date. If a cache device fails, a file that is cached in writeback mode may not be completely present on the disk. SmartIO has a mechanism to flush the data from the cache device when the device comes back online. Storage Foundation Cluster File System High Availability (SFCFSHA) provides additional protection from data loss with cache reflection.
In the case of SFCFSHA, when writeback mode caching is enabled, SmartIO mirrors the write-back data at the file system level to the other node's SSD cache. This behavior, called cache reflection, prevents loss of write-back data if a node fails. If a node fails, the other node flushes the mirrored dirty data of the lost node as part of reconfiguration. Cache reflection ensures that write-back data is not lost even if a node fails with pending dirty data.
In the case of local mount, if there is no cache mirror, the disk copy of the file can be incomplete or stale if the node fails.
After write-back caching is enabled on the mount point, the qualified synchronous writes in that file system are cached. SmartIO determines if a write qualifies for write-back caching, using criteria such as the following:
The write request must be PAGESIZE aligned (multiple of 8k). For Oracle redo logs, the writes use the redo log block size, which cannot be changed to 8k. Therefore, redo log writes are not cached in the write-back cache.
The write request is not greater than 2MB.
The file on which the writes are happening is not mmapped
The writeback mode caching is not explicitly disabled by the administrator.
You can also customize which data is cached, by adding advisory information to assist the SmartIO feature in making those determinations.