In an S2D configuration, the individual disks are pooled together, and the operating system interacts with the aggregated storage pool rather than individual disks.
This abstraction reduces the direct control or visibility over how specific disks are utilized for data, logs, or other purposes.
For caching :
- Read-only caching is beneficial for workloads that are read-heavy and do not frequently write to the disk like SQL data files for reads
- None (No caching) is typically preferred for write-heavy workloads (transaction log files) to avoid double writes and latency.
- Read/Write caching is generally not recommended for SQL Server workloads because it may introduce inconsistencies or performance degradation in write-heavy operations.
For disks being added to the S2D pool, None (No caching) is the recommended setting. This is because S2D handles caching and data management internally, and Azure host caching can interfere with or duplicate this functionality.
SQL Server data and log files will reside on the volumes created from the S2D pool. Since these volumes abstract away the underlying disks, the host caching settings will have minimal direct impact on SQL Server performance if configured uniformly as None
for all disks in the pool.