Sun Storage 9970 System
 
Sun Storage 9990 System
 
Sun Storage 9985 System
 
Sun Storage 9960 System
 
Sun Storage 9980 System
 

GCS>Sun Microsystems>Storage - Disk>Datacenter Disk
 

The slots are equal in size to an LDEV's track. Therefore, the larger the track size, the more cache is consumed with each I/O. For example, if one reads 512  bytes of data from a logical device with a 256k track size, then the 512 requested bytes, plus the next 261632 bytes, are read into cache, thus filling a 256k cache slot. This may be very advantageous for sequential I/O patterns, but less so for small, random I/O.  

The next largest segment of an LDEV is called a stripe chunk.  A stripe chunk consists of 2 or 8 tracks, depending on the emulation type (see Table 1 below). For example, a stripe chunk for an OPEN-E LDEV would consist of eight 48k tracks, or 384k.  A stripe chunk is the largest unit of data written to a single physical device in one operation. A full stripe ranges from 768k to 2688k, depending on the number of data stripe chunks in the RAID type. For example, the stripe size for a RAID1 2+2 OPEN-E LDEV is (2)(384) = 768k.

The OPEN-V emulation was introduced in the Sun StorEdge 9970 (SE9970) and Sun StorEdge 9980 (SE9980) products.  The track size for the new emulation was raised to 64k, which in turn increased the associated stripe chunk and stripe sizes, as noted in Table 1. With the introduction of SE9990/SE9985, the default track and cache slot size for OPEN-V has been increased from 64k to 256k. However, an option to use the 64k device geometry was provided, as discussed in <Document: 1002348.1>  The default OPEN-V stripe chunk remains at 512k (2 tracks), thus requiring less work for RAID5 parity generation (this is discussed in more detail below). Therefore on SE9990/85, it is theoretically possible to gain efficiencies in cache management by using the OPEN-V emulation. However, performance testing has shown that for many workloads, there is no significant difference between the newer and the original OPEN-V device geometry.  Also, non-OPEN-V emulations may perform as well as or better than OPEN-V for small random I/O.

For RAID5 logical devices, parity must be generated.  This is done on the dynamic regeneration and recovery (DRR) processor on the disk adapter (DKF or DKA).  The number of parity cycles (processor cycles) required for parity generation varies with the type of logical device, as noted in Table 1 below.  If full stripe writes are done, the array does not need to read old data and old parity in order to generate parity for the current operation, but rather can generate parity from the data already in cache. Therefore it is advantageous to use the information in this article to tune host I/O to maximize the chances for full stripe writes to occur.  In addition, Hitachi caching algorithms attempt to maximize efficiency by accumulating a full stripe of data in cache, prior to writing the data to disk, if possible.

Table 1

The parameters in Table 1 are useful to keep in mind when tuning the I/O subsystem.  For example, consider matching the volume manager stripe unit size to a multiple of the track size.  For small I/O, one might simply match the stripe unit size to the track size, while for larger I/O, one might want to match the stripe chunk or even the full stripe size.

This solution has no attachment