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

GCS>Sun Microsystems>Storage - Disk>Datacenter Disk
 

LUSE is used to create logical devices (LDEVs) larger than the standard StorEdge 9900 (SE9900) device emulations.  When employing LUSE, a number of   standard  size LDEVs are concatenated into a single large LDEV, which is then presented to the host as a single logical unit (LUN).  LUSE is particularly useful for creating large volumes when there is no host volume manager available.  On the other hand, if a host volume manager is available, many administrators prefer to use the volume manager instead of LUSE, since volume managers permit greater flexibility in tuning the volumes to the requirements of the application by adjusting blocking factors, stripe unit sizes, etc.

We will consider two basic types of LUSE volumes.  One type of LUSE volume has LDEVs added to the LUN in sequential order. All component LDEVs would be drawn from a single array group until its capacity is exhausted, and so forth.  This "sequential" type of LUSE is good for single-threaded sequential I/O such as backups. Applications would access these volumes in a sequential pattern using no more than a few threads.  The  I/O profile is such that only four or eight disks are accessed simultaneously.  Multi-threaded, random I/O would NOT perform well on this type of LUSE.  Figure 1 shows a portion of the Storage Navigator screen associated with creating a sequential LUSE.  Note that since this array has been set up with linear addressing, the consecutively numbered LDEVs in this LUSE volume will all be drawn from the same parity group, thus creating a sequential LUSE.

Another LUSE type is (ideally) constructed from only one LDEV per array group.  Figure 2 shows a LUSE setup screen in which the component LDEVs all come from different parity groups.  Multiple ACP pairs may also be involved.  This  dispersed  type of volume is well-suited for multi-threaded random I/O such as file systems and OLTP.  Potentially, all disks in the volume could be simultaneously active.  However, note that if the LUN is only 1/4 populated with user data, for example, only a fraction of the disks may be used (thus limiting performance) until the LUN is more fully populated.  In addition, note that even very large LUSE LUNs will have the same host-based ssd_max_throttle (queue depth) limits as any ordinary LUN.  See <Document: 1003338.1> for additional discussion of queue depth.

Another good practice is to offset the starting LDEV in LUSE volumes to include different array groups and ACP pairs.  The beginning of a LUN will tend to be accessed heavily when applications initialize and / or refer to data structures stored in that location. Offsetting the starting LDEV so that the first LDEV in each LUSE volume is located on different array groups and ACP pairs will help to avoid contention.

This solution has no attachment