DS8000 Storage Allocation Overview V1.0a

IBM DS8000 Storage Allocation Overview
IBM DS8000 Storage Allocation Overview Including Thin Provisioning
Version 1.0a September 28, 2009
Rick Ripberger Enterprise Disk Architecture Dept CSVA/9032-1 IBM Tucson Yan Xu Performance Dept KBVA/9062-2 IBM Tucson
WP101550
Copyright IBM Corporation, 2009
9/28/2009 Page 1
Summary of Changes
The following versions of the document have been released with the indicated changes: 1. Version 1.0, September 8, 2009 This is the initial document version. 2. Version 1.0a, September 23, 2009 The following changes were made: Added section numbers. Corrected some typos in the initial version in blue.
WP101550
9/28/2009 Page 2
Table of Contents
Summary of Changes.......................................................................................................... 2 Table of Contents................................................................................................................ 3 1 Summary ..................................................................................................................... 4 2 Feature Availability .................................................................................................... 4 3 Storage Allocation Concepts....................................................................................... 4 4 Storage Allocation on DS8000 ................................................................................... 7 4.1 Standard Logical Volumes.................................................................................. 8 4.2 Extent-Space-Efficient Logical Volumes ........................................................... 9 4.3 Track-Space-Efficient Logical Volumes .......................................................... 11 4.4 Volume Expansion............................................................................................ 13 4.5 Capacity Utilization .......................................................................................... 14 4.6 Capacity Utilization Management .................................................................... 16 4.7 Capacity Planning Example.............................................................................. 17 4.8 Extent Allocation .............................................................................................. 22 4.9 Capacity Initialization....................................................................................... 24 4.10 DS8000 Copy Services ..................................................................................... 25 5 Thin Provisioning Considerations ............................................................................ 26 5.1 IBM AIX/JFS2 File System with DS8000 Thin Provisioning ......................... 28 5.2 Thin Provisioning Software .............................................................................. 36 5.3 DS8000 Thin Provisioning and Quick Initialization Performance ................... 36
WP101550
9/28/2009 Page 3
1 Summary
This white paper discusses storage allocation on the DS8000. The discussion covers existing storage provisioning methods as well as the new Thin Provisioning facility and the Quick Initialization function. Thin provisioning is a method of configuring one or more logical volumes such that capacity for data stored on the logical volume is not allocated until the data is written. This deferred allocation may result in improvements in storage utilization and a reduction in storage management as compared to standard logical volumes. This document is intended to provide an overall understanding of how thin provisioning works on DS8000 and to help the user to assess what environments may benefit from using this facility. Quick Initialization dynamically initializes logical volumes when they are created or expanded allowing logical volumes to be configured and placed online more quickly.
2 Feature Availability
Thin Provisioning The DS8000 thin provisioning (TP) facility became generally available on DS8100 and DS8300 storage facilities with LIC version 64.30 which was released in August 2009. To utilize the facility, a supporting LIC level must be installed on the storage facility image and additionally, the customer must order and install the DS8000 Thin Provisioning LIC feature. Once enabled, the facility allows any newly configured logical volume with 512byte fixed blocks to be configured as a thin provisioned logical volume. To disable the LIC feature, any thin provisioned logical volumes must be deleted and a disablement LIC feature key must be installed. Quick Initialization The DS8000 quick initialization (QI) facility became generally available on DS8100 and DS8300 storage facilities with LIC version 64.30 which was released in August 2009. This function is used implicitly and replaces the previously released FlashInit function. Note: Thin provisioning is not supported on zSeries Count-Key-Data (CKD) logical volumes and iSeries 520-byte fixed block logical volumes at this time. Quick initialization is not supported on CKD logical volumes at this time. Note: The DS8000 copy services facilities are not supported on thin provisioned volumes at this time. The storage facility image does not prevent the invocation of copy services, but these functions should not be invoked on thin provisioned volumes. Existing copy services facilities can continue to be used on non-thin-provisioned logical volumes even when there are thin provisioned logical volumes configured.
3 Storage Allocation Concepts

On DS8000, a logical volume is provisioned by one of the following methods:
WP101550
9/28/2009 Page 4
IBM DS8000 Storage Allocation Overview Allocate Capacity at Creation The logical volume allocates all capacity required to store any data that may ever be written to the volume when the logical volume is created. The logical tracks on the logical volume are pre-initialized with an initialization pattern when it is created. Accesses to data in logical tracks on the logical volume result in stage and destage operations being directed to the appropriate logical track on the allocated capacity. A logical volume that allocates all of its capacity at creation is referred to as a standard logical volume. Allocate Capacity on Write The logical volume allocates sufficient capacity to store any metadata required to manage the volume when the logical volume is created. Subsequent to volume creation, the volume behaves as follows in response to access to data in logical tracks on the logical volume: On a read access, if the logical track is not already in the read cache and the capacity for the logical track is not allocated or not initialized, the stage operation for the read causes data for the logical track to be synthesized in the read cache with an initialization pattern that is present in an unwritten track on a standard logical volume. On a read access, if the logical track is not already in the read cache and the capacity for the logical track is allocated and initialized, a stage operation is directed to the appropriate logical track on the allocated capacity. On a write access, if the capacity for the logical track is not allocated, the storage facility image dynamically allocates capacity to the logical volume that is needed to store the write data. This may occur at write time or at destage time depending on the case being considered. The write data is stored in the write cache and eventually causes a destage operation to be directed to the appropriate logical track(s) on the allocated capacity. If the capacity allocated is larger than the data to be written, the storage facility image has an initiative to initialize any unwritten allocated capacity before it is read. On a destage, if the target track has not been previously initialized, any unwritten portions of the track are initialized as part of the destage processing. Additional adjacent tracks may also be initialized as part of the destaged processing depending upon the case.
Refer to 4.9, "Capacity Initialization", for more information on track initialization patterns. A logical volume that allocates capacity on writes is referred to as a space-efficient logical volume. The amount of capacity available to provision a set of space-efficient logical volumes may be less than the capacity represented by the sum of the capacities of the space-efficient logical volumes. This practice is referred to as storage overcommitting. A customer configuring an over-committed volume generally estimates how much space the volume will ultimately need and perhaps adds some contingency to this
WP101550
9/28/2009 Page 5
IBM DS8000 Storage Allocation Overview to handle any inaccuracy in the estimate. The actual storage used by the volume may change over time, and may be more or less than the amount estimated. By pooling the capacity used to provision a set of space-efficient logical volumes, deviations in allocation requirements of specific logical volumes tend to average out over the aggregate. Thus, while some volumes may need more than was estimated, others may need less, so across the set of volumes, the pool capacity needs to handle the average storage requirement across the set of volumes. This makes the amount of tolerable overcommitment more predictable. The amount of storage over-committing that can be tolerated without encountering out of space conditions depends on the applications using the space-efficient logical volumes, the granularity of capacity allocated to a spaceefficient logical volume, and the rate at which any capacity is consumed versus the rate it is released. In general, there is a trade-off between space-efficiency and performance that depends on the granularity of capacity allocation. A small granularity capacity allocation leads to the best space efficiencies, but may have performance implications because of the frequency of overheads involved with accessing metadata that determines whether a unit of capacity is allocated or not and because of the frequency of overheads involved with allocating a unit of capacity. Sequential performance may be affected if the capacity allocations do not maintain a sequential ordering of sets of logical tracks on the logical volume within the allocated capacity. A large granularity capacity allocation may be less space efficient for some applications, but tends to have more optimal performance due to the reduction in the number of necessary capacity allocations, the reduction in the number of metadata accesses, and better grouping of sequential logical tracks into capacity allocations. The way that an application accesses data may determine what storage provisioning method should be used for a logical volume based on the resulting performance and storage allocation characteristics. In general, a space-efficient logical volume may be used if either there is some mechanism to determine when to release physical space associated with the logical volume or if the application is well behaved such that it limits where it stores data on the volume to prevent the allocation of more capacity than is required to store the active data on the volume. Thin Provisioning With an appropriate application, thin provisioning is intended to provide the customer with the following benefits: A reduction in storage management overheads through exploiting the ability to over configure logical volumes used in database or file system applications without requiring the underlying capacity to be present. Subsequent growth in the file system or data base capacity may require the addition of storage to a storage facility, but this additional capacity can be applied to thin provisioned volumes which are already preconfigured within the software stack for the additional capacity. An improvement in storage utilization efficiencies achieved by aggregating any contingency capacity, typically pre-allocated to a set of users or applications on a per
WP101550
9/28/2009 Page 6
IBM DS8000 Storage Allocation Overview user or application basis, into a shared contingency pool. This is achieved by provisioning a set of space-efficient volumes that share a common, dynamicallyallocated storage allocation pool. By sharing a common capacity contingency pool, inaccuracy in estimating the amount of contingency capacity required for any one user or application may be averaged across the set of users or application, resulting in both dynamic reallocation of the contingency based on actual usage and a potential reduction in the total amount of contingency capacity required assuming that not all users and applications will require their entire estimated contingency. Based on an improvement in storage utilization efficiencies, storage capacity acquisitions may be reduced or at least deferred to a later time.
In cases where an application requires more capacity than is available for provisioning a set of over-committed space-efficient logical volumes, DS8000 rejects write accesses that require the allocation of capacity on the set of space-efficient logical volumes until more capacity is made available for allocation. The storage facility image provides certain mechanisms to monitor and report when the available space crosses a user defined threshold to enable monitoring of this condition.
4 Storage Allocation on DS8000

This section provides a general overview of how capacity is allocated to logical volumes on DS8000. Prior to configuring a logical volume, the user creates one or more extent pools on a DS8000. Each extent pool consists of one or more ranks, each of which is composed of one RAID array. Each rank is divided into a number of fixed sized extents which can then be allocated to logical volumes. The RAID arrays within an extent pool generally have homogenous characteristics relative to extent type (size and disk emulation), disk RPM, disk data rate, and RAID type. Logical volumes limit their capacity allocations to a set of extents within a single extent pool such that the storage characteristics of the logical volume are consistent with the storage characteristics of the extent pool, and such that the failure boundary of a logical volume is limited to the set of disks configured in its associated extent pool. In a fixed block extent pool, an extent is 1 GB (230 bytes) of customer data. In a CKD extent pool, an extent is 1113 cylinders (about 0.94 GB) and is referred to as a "Mod 1 equivalent". When a logical volume is configured, it is always associated with one and only one extent pool. The storage allocation method (SAM) attribute specified when a logical volume is configured determines whether the logical volume is a standard logical volume (Std LV), extent-space-efficient logical volume (ESE LV), or a track-space-efficient logical volume (TSE-LV). Any of the three types of logical volumes can be configured in a given extent pool as will be discussed. To support space-efficient logical volumes, the storage facility requires a place to store certain persistent information as will be described in more detail subsequently for each type of space efficient volume. To provide a place to store this information, one or more
WP101550
9/28/2009 Page 7
IBM DS8000 Storage Allocation Overview logical spaces are configured in the extent pool that allocate one or more real extents and that are not accessible to any attached host. Note: The term "Mod 1 equivalent" is based on legacy IBM 3390 CKD device models where the model numbers were indicative of the capacity of the device. For instance a 3390 Model 1 had 1113 cylinders, a 3390 Model 2 had 2x1113 = 2226 cylinders, a 3390 Model 3 had 3x1113 = 3339 cylinders, and a 3390 Model 9 had 9x1113 = 10017 cylinders. Logical devices that have a capacity of N x 1113 cylinders (i.e. that are the size of an integral number of Mod 1 extents) are sometimes referred to as a Mod N logical device). Each cylinder contained fifteen 3390 data tracks, each track containing up to 56,664 customer data bytes, depending on the track format. Note: When using the DS/GUI with LIC version 64.30 or above, virtual storage is transparently created in an extent pool as required when the user configures one or more ESE or TSE logical volumes. When using the DS/CLI, virtual storage must be explicitly configured using the mksestg command. Note: A space efficient repository must be explicitly configured by the user. In DSCLI, the mksestg command is used to configure a space efficient repository.
4.1 Standard Logical Volumes

Figure 1 shows a standard logical volume (Std LV) provisioned within an extent pool. Ranks that are composed of physical disks and the extents provided by these real ranks are referred to as real extents. A real extent provides space for one extent's worth of customer data and additionally provides some space for metadata required to manage the real extent. The amount of extent metadata required is very small compared to the customer data stored in a real extent. When capacities of real ranks are provided, they are expressed in terms of the customer usable data capacities. A standard logical volume is configured with a user specified capacity. When created or expanded, the logical volume allocates one or more real extents from an extent pool to provide sufficient capacity to provision the user specified capacity. If the user specified capacity is not an integral number of extents, the capacity at the end of the last real extent allocated to the logical volume is not accessible unless the volume is expanded. When real extents are allocated to a fixed block standard logical volume, a process called Quick Initialization (or Quick Init) is invoked to dynamically initialize the logical tracks on the logical volume while it is accessible to the host. When a standard logical volume is deleted, all real extents allocated to the logical volume are released and become available for reallocation. Writes issued to a logical volume extent may eventually result in destages to the associated real extent. Reads issued to logical tracks that have a real extent allocated and have been previously initialized or written may result in stages from the allocated real extent. Reads issued to logical tracks that have real extent allocated, but have not been previously initialized or written, cause an initialized track to be synthesized in cache.
WP101550
9/28/2009 Page 8

IBM System Storage
Standard Logical Volumes

Standard LV consists of 1 N real extents
Extent Pool Standard LV
Each real extent contains extent data And extent metadata
M M M
Each LV extent is mapped to a real extent on a rank
Rank
M M M M M M
All extents allocated to a logical volume come from one extent pool
FB Extent
= 1024 MB Extent Data (Customer) 4.5 MB Extent Metadata (+0.439%)
Extent Data
Extent Metadata
DS/8000 Storage Allocation
2009 IBM Corporation
Figure 1. Standard Logical Volume Provisioning
4.2 Extent-Space-Efficient Logical Volumes

Extent-space-efficient logical volumes are used in conjunction with the Thin Provisioning facility. Thin provisioning and extent space efficient logical volumes are only supported on fixed block logical volumes. Figure 2 shows an extent-space-efficient logical volume (ESE LV) provisioned within an extent pool. An ESE LV requires metadata for each extent even when there is no customer data associated with an extent. To provide a space to store this metadata, virtual storage is configured. The logical space of the virtual storage provides a set of virtual extents that can be allocated to space-efficient logical volumes. Each virtual extent provides the metadata normally associated with a real extent. The capacity of virtual storage is described in terms of the number of virtual extents it provides which determines the amount of space-efficient logical capacity it can support. Since the amount of extent metadata is small compared to the amount of customer data in a real extent, the capacity of virtual storage is large compared to the real capacity allocated within the extent pool to create the logical space for virtual storage. Within a given extent pool, virtual and real extents are the same logical size (i.e. they support the same amount of logical volume capacity). An ESE LV is configured with a user specified capacity. When created or expanded, the logical volume is allocated one or more virtual extents from an extent pool to provide
WP101550
9/28/2009 Page 9
IBM DS8000 Storage Allocation Overview sufficient capacity to provision the user specified capacity. If the user specified capacity is not an integral number of extents, the capacity at the end of the last virtual extent allocated to the logical volume is not accessible unless the volume is expanded. When an ESE LV is deleted, all real and virtual extents allocated to the logical volume are released and become available for reallocation. Space on an existing ESE LV can be released by requesting volume initialization through the user configuration interfaces or, on fixed block logical volumes, by issuing a SCSI Format Unit command. When space is released from an ESE LV, the real extents that are released become available for reallocation. When a host writes data to an extent on an extent space efficient logical volume, if the extent does not have an associated real extent, the write is held in abeyance until a real extent from the extent pool is dynamically allocated to the logical volume (now both a virtual extent and real extent are allocated for this extent) so that there is a place to store the customer data. Subsequently the write data is accepted into the write cache and eventually results in one or more destages to the allocated real extent. Whenever a real extent is allocated to a fixed block ESE LV, a process call Quick Initialization (or Quick Init) is invoked to dynamically initialize the tracks on the real extent that have not been written. This initialization is performed in parallel with host access to the associated extent. Any subsequent writes to a logical volume extent which has an allocated real extent eventually result in one or more destage to the allocated real extent. Reads issued to logical tracks that have a real extent allocated and have been previously initialized or written result in stages from the allocated real extent. Reads issued to logical tracks that do not have a real extent allocated, or that have real extent allocated but have not been previously initialized or written, cause an initialized track to be synthesized in cache. In order to configure an ESE logical volume, there must be sufficient available virtual extents in the extent pool to support the logical volume. Virtual storage can be configured in an extent pool through the configuration interface. Virtual storage can be created or expanded as required up to the limits supported as discussed in section 4.5, "Capacity Utilization". Virtual storage can be deleted from an extent pool if there are no TSE or ESE logical volumes configured in the extent pool. The behavior of an extent-space-efficient logical volume is virtually identical to a standard logical volume for a given logical volume extent which has allocated a real extent. As such, the performance of I/O operations on such an extent should be virtually identical to that of a standard logical volume. Additionally, the overheads to I/O operations that access an unallocated extent on an extent space efficient logical volume are primarily limited to the overhead involved with real extent allocation. Since there are a large number of tracks per extent, the number of extent allocations that might occur is relatively limited. Additionally, if the application is well behaved for a thin provisioned logical volume, the rate at which extent allocations occur is also relatively infrequent. As such, ESE logical volumes generally have performance that is relatively comparable to standard logical volumes. Both standard and ESE fixed block logical volumes have some background overhead related to quick initialization of extents, but the overhead occurs at different times. The extents on a standard logical volume are all allocated and begin quick initialization at volume creation, while the extents on an ESE volume are allocated and begin quick initialization as they are first written. This overhead may or may not be
WP101550
9/28/2009 Page 10
IBM DS8000 Storage Allocation Overview noticeable and is similar to the overheads associated with a background FlashCopy operation. See section 5.3, "DS8000 Thin Provisioning and Quick Initialization Performance", for more information on the performance of ESE volumes. The one potential issue with ESE logical volumes relative to thin provisioning is their granularity of allocation which may make them unsuitable for applications that are not well behaved (see section 5.2, "Thin Provisioning Software").
IBM System Storage
Extent Space Efficient Logical Volumes

Extent Pool Extent Space Efficient LV consists of 1 N Extents Each ESE LV extent is mapped to a virtual extent (a virtual extent provides only extent metadata). One or more real extents are allocated to provision space for the virtual extents in virtual storage . If host writes to a ESE LV extent, a real extent on a rank is allocated to the LV extent, if it is not already allocated, and QuickInit is invoked to initialize the extent. If a host reads from an ESE LV extent that has no real extent, an initialized track is synthesized. All real and virtual extents allocated to an ESE LV come from the LVs Extent Pool The capacity for the metadata in virtual storage is from real extents allocated to provision virtual Storage. FB Virtual Storage Real Extent = 227.555 FB Virtual Extents Real/Virtual = 0.439%
DS/8000 Storage Allocation 2009 IBM Corporation
Extent SE LV
M M M
Rank
M M M M M M
Real Extents used to Provision Virtual Storage

MMMMMM MMMMMM
Virtual Storage
M M M M M M
Figure 2. Extent-Space-Efficient Logical Volumes
4.3 Track-Space-Efficient Logical Volumes

Track-space-efficient logical volumes are used in conjunction with the Space-Efficient FlashCopy facility. Space Efficient Flash Copy and track-space-efficient logical volumes are supported on both fixed block and CKD logical volumes. Figure 3 shows a track-space-efficient logical volume (TSE LV) provisioned within an extent pool. A TSE LV requires metadata for each extent even when there is no customer data associated with an extent. To provide a space to store this metadata, virtual storage is configured. The logical space of the virtual storage provides a set of virtual extents that can be allocated to space-efficient logical volumes. Each virtual extent provides the metadata normally associated with a real extent. The capacity of virtual storage is described in terms of the number of virtual extents it provides which determines the amount of space-efficient logical capacity it can support. Since the amount of extent
WP101550
9/28/2009 Page 11
IBM DS8000 Storage Allocation Overview metadata is small compared to the customer data normally stored in a real extent, the capacity of virtual storage is large compared to the real capacity allocated within the extent pool to create the logical space for virtual storage. Within a given extent pool, virtual and real extents are the same logical size (i.e. they support the same amount of logical volume capacity). A TSE LV allocates capacity for customer data with a logical track granularity. On a fixed block logical volume, a logical track is 64K bytes or 128 512-byte logical blocks. On a CKD logical volume, a logical track is one CKD track (3380 or 3390 track format depending on type of CKD volume). CKD tracks are stored on 112 512-byte logical blocks. To provide a logical space to store the data associated with TSE LVs, another logical space referred to as a space-efficient repository, is configured in the extent pool. The space efficient repository has associated repository metadata that is used to map between a logical track on a TSE LV and an allocated logical track in the space efficient repository. This metadata is allocated within the space efficient repository at a rate that is proportional to the customer usable size of the space efficient repository. The logical tracks in the space efficient repository are referred to as real logical tracks. A TSE LV is configured with a user specified capacity. When created or expanded, the logical volume is allocated one or more virtual extents from an extent pool to provide sufficient capacity to provision the user specified capacity. If the user specified capacity is not an integral number of extents, the capacity at the end of the last virtual extent allocated to the logical volume is not accessible unless the volume is expanded. When a TSE LV is deleted, all real logical tracks and all virtual extents allocated to the logical volume are released and become available for reallocation. When space is released from a TSE LV, the real logical tracks that are released become available for reallocation. When a host writes (or a FlashCopy operation copies) data to a logical track on a track space efficient logical volume, if the logical track does not have an associated real logical track, the resulting destage is held in abeyance until a real logical track from the space efficient repository is dynamically allocated to the logical volume and initialized so that there is a place to store the customer data. Reads issued to logical track that have a real logical track allocated result in stages from the allocated real extent. Reads issued to logical tracks that do not have a real logical track allocated cause an initialized track to be synthesized in cache. In order to configure a TSE logical volume in an extent pool, there must be sufficient available virtual extents in the extent pool to support the logical volume and there must also be a space efficient repository configured. Virtual storage and a space efficient repository can be configured in an extent pool through the configuration interface. Virtual storage can be expanded as required up to the limits supported as discussed in section 4.5, "Capacity Utilization". A space efficient repository cannot be expanded once it is created. A space efficient repository can be deleted from an extent pool if there are no TSE logical volumes configured in the extent pool. Virtual storage can be deleted from an extent pool if there are no TSE or ESE logical volumes configured in the extent pool. The behavior of a track-space-efficient logical volume differs from a standard logical volume in that each track access must process repository metadata to determine if the
WP101550
9/28/2009 Page 12
IBM DS8000 Storage Allocation Overview logical track being processed is allocated in the space-efficient repository, and if allocated, to determine the location of the logical track within the space-efficient repository. Additionally, since tracks are allocated when written, random write accesses can result in a random ordering of logical tracks within the repository for logical tracks that are sequentially ordered on the track-space-efficient volume. Both of these characteristics can have implications for the performance of track space efficient logical volumes that may affect its applicability to a given workload. The smallness of the granularity of capacity allocation with track-space-efficient logical volumes provides excellent space efficiency. IBM currently limits the support of track-space-efficient logical volumes to FlashCopy targets used in conjunction with the Space-Efficient FlashCopy facility.
IBM System Storage
Track Space Efficient Logical Volumes

Track Space Efficient LV consists of 1 N Tracks Each TSE LV extent is mapped to a virtual extent (a virtual extent provides only extent metadata) If host writes to a TSE LV track, a real track in a space efficient repository is allocated to the LV track, if it is not already allocated. The mapping from the LV track to the repository track is maintained in repository metadata. If a host reads a TSE LV track that has no logical track, then an initialized track is synthesized. All virtual extents allocated to a TSE LV come from the LVs extent pool. All real tracks allocated to TSE LV come from the one SE repository In the LVs extent pool. The capacity for the virtual storage and SE Repository is configured with real extents from a rank in the extent pool. FB Repository Real Extent = 16K Tracks = 1GB 1 Rep Metadata Extent for each 91 Rep Data Extents (+1.1%) Track SE LV Extent Pool
M M M
SE Repository
Tracks
Rank
M M M M M M
Rep. Metadata
Capacity for Virtual Storage

MMMMMM MMMMMM
Virtual Storage
M M M M M M
Figure 3. Track-Space-Efficient Logical Volumes
4.4 Volume Expansion

The capacity of an existing logical volume can be expanded. To expand a logical volume, the user specifies a new requested capacity for the logical volume. If additional extents must be allocated to support the expansion, the extents are allocated and initialized as
WP101550
9/28/2009 Page 13
IBM DS8000 Storage Allocation Overview described in sections 4.8, "Extent Allocation", and 4.9, "Capacity Initialization". Existing capacity remains accessible to the host during the expansion and the additional capacity becomes host accessible once the configuration operation completes. Virtual storage in an extent pool can be created or expanded. To create or expand the virtual storage in an extent pool, the user requests virtual storage capacity in excess of the currently configured virtual storage capacity. The request creates or expands the virtual storage logical space as required in the extent pool to achieve the requested virtual storage capacity. A space efficient repository can be created, but not expanded. To create a space efficient repository in an extent pool, the user requests repository capacity to be configured. The request creates a space efficient repository logical space in the extent pool to achieve the requested space efficient repository capacity. Volume expansion is not supported on a logical volume that has an existing copy services relationship. Volume expansion is supported on a logical volume that is in the process of Quick Init.
4.5 Capacity Utilization

Figure 4 shows how capacity is utilized within an extent pool. A given extent pool is configured with one or more ranks that provide a number of real extents within the extent pool. The capacity associated with the set of real extents is referred to as real capacity. A given rank within the extent pool can be placed in the reserved or normal state through the configuration interface. When it is in the normal state, all extents on the rank are allocatable to logical volumes, virtual storage, and a space efficient repository. When it is in reserved state, any extents which are not currently allocated are considered reserved and are not allocatable. Although not typically needed, rank reservations can be used to target extent allocations to specific ranks within an extent pool or to hold some capacity within the extent pool in reserve for future usage. The capacity associated with the set of reserved real extents is referred to as reserved real capacity. Any real capacity in the extent pool that is not reserved is considered allocatable real capacity. Allocatable real capacity can be either allocated real capacity or available real capacity. When it is allocated, real capacity is allocated to logical volumes (LVs), virtual storage, or a space efficient repository. Real extents are statically allocated to standard logical volumes, virtual storage or a space efficient repository as shown in the blue region of the real capacity. If virtual storage is configured, it provides a certain number of virtual extents. The capacity associated with the set of virtual extents is referred to as virtual capacity. All virtual capacity is allocatable to either ESE or TSE logical volumes within the extent pool. If a space efficient repository is configured, it provides repository capacity for all TSE logical volumes in the extent pool. When ESE logical volumes require a real extent to store data, they dynamically allocate a real extent from the available real capacity. Any available real capacity remaining in the extent pool is available to either ESE dynamic extent allocations or to other static extent allocations. The level of over commitment for the ESE logical volumes is calculated as
WP101550
9/28/2009 Page 14
IBM DS8000 Storage Allocation Overview the ratio of the ESE allocated virtual capacity (V1) to ESE allocatable real capacity (R1). The ESE allocatable real capacity is the sum of the ESE allocated real capacity (red area) and the available real capacity. As shown, R1 is affected by the amount of reserved real capacity and the amount of statically allocated real capacity (blue area) so the user must be careful when planning the configuration of the extent pool to ensure that the desired over commit ratio is maintained over time. As discussed in section 4.6, "Capacity Utilization Management", an extent threshold can be set on the extent pool to monitor when allocated real capacity has exceed a customer specified threshold. When TSE logical volumes require a real logical track to store data, they dynamically allocate a real logical track from the available repository capacity. The level of over commitment for the TSE logical volumes is calculated as the ratio of the TSE allocated virtual capacity (V2) to TSE allocatable repository capacity (R2). The TSE allocatable repository capacity is the sum of the TSE allocated capacity and the available repository capacity. As discussed in section 4.6, "Capacity Utilization Management", a repository threshold can be set on the space efficient repository to monitor when allocated repository capacity has exceed a customer specified threshold. A given storage facility image is limited to a total of 4M (4x220) extents (real + virtual). This limit applies to the sum of all real and virtual extents in all extent pools. A given extent pool is limited to a maximum of 2M (2x220) virtual extents.
IBM System Storage
Extent Pool Logical Space

Real Capacity Virtual Capacity
ESE Virtual LV Reserved
Repository Threshold Extent Threshold
Repository Capacity
TSE Tracks Available
V1
ESE / STD Available
R1
ESE Extents Allocated TSE Virtual LV TSE Tracks Allocated
R2
V2
Standard Extents Allocated Virtual Storage Repository
Allocatable ESE Over-commit: V1 : R1 TSE Over-commit: V2 : R2

LV
Extent Pool
Figure 4. Extent Pool Logical Space
WP101550
9/28/2009 Page 15
4.6 Capacity Utilization Management

It is possible for a given workload to attempt to write more data to a set of space efficient logical volumes than the underlying real capacity configured for the logical volumes can support. If this occurs the storage facility image behaves as follows: If an extent pool has no available real capacity, any write to any ESE LV in the extent pool that requires the allocation of a real extent is rejected. If a space efficient repository >= 99% full, any write to any TSE LV in the extent pool that requires the allocation of a real logical track is rejected.
The storage facility image provides the following mechanism to assist in managing space efficient capacity: For ESE volumes, there is an extent threshold and extent status attribute on the extent pool. The extent threshold indicates a percentage of available real capacity that the customer is interested in as a boundary condition. The %Available Real Capacity for the extent pool is calculated as Available Capacity / Allocatable Capacity. The extent threshold defaults to 15% but can be set to any value between 0% and 100% by the customer. As show in Figure 4 in section 4.5, "Capacity Utilization", the allocatable and available capacities do not include reserved capacity. The extent status attribute is set to a value based on the relationship of the extent threshold to the %available real capacity for the extent pool as follows: Extent Status Full Exceed Below %Available Real Cap. = 0 Ext. Threshold >= %Avail. Real Cap. > 0 %Avail. Real Cap. > Ext. Threshold Condition No Space Space Low Space Available
When there are ESE logical volumes configured in the extent pool, an SNMP trap is generated when the extent status attribute changes state. An SNMP trap is also generated when the first ESE volume is configured in the extent pool if the extent status is not currently set to below. For TSE volumes, there is a repository threshold and a repository status attribute on the space efficient repository. The repository threshold indicates a percentage of available repository capacity that the customer is interested in as a boundary condition. The %Available Repository Capacity for the space efficient repository is calculated as Available Repository Capacity / Repository Capacity. The repository threshold defaults to 15% but can be set to any value between 0% and 100% by the customer. The repository status attribute is set to a value based on the relationship of the repository threshold to the %available repository capacity for the space efficient repository as follows: Repository Status Full Exceed Below Condition No Space Space Low Space Available
%Available Real Cap. = 0 Rep. Threshold >= %Avail. Real Cap. > 0 %Avail. Real Cap. > Rep. Threshold
WP101550
9/28/2009 Page 16
IBM DS8000 Storage Allocation Overview An SNMP trap is generated when the repository status attribute changes state. An SNMP trap is also generated when the repository capacity crosses the 15% available condition.
4.7 Capacity Planning Example

Storage capacity planning is a process performed by the customer to determine what storage capacity and I/O bandwidth are required for the set of customer applications over a period of time, to determine how that storage capacity and bandwidth will be provisioned through the configuration of one or more storage subsystems attached to the hosts that run the customer applications, and to determine what storage capacity acquisitions are required over time to support the application requirements. In general, the overall objective of the process is to ensure that the storage infrastructure supporting the customer application environment is capable of growing to meet the needs of the business and that the cost of any storage acquisitions is minimized and meets any customer-imposed budgetary constraints. In planning how to provision any required capacity, the customer must understand how a given storage subsystem can expand its capacity over time and how the installed capacity can be configured to provide usable customer capacity. By having a plan for the evolution of the storage facility configuration over time, the customer may be able to make choices on over-provisioning his storage to minimize the amount of storage management effort involved in configuring the software stack to expand the capacity over time as well as to leverage the efficiencies of pooling contingency capacity inherent with the thin provisioning facility to defer or avoid storage acquisitions. This section provides an example of how the user can utilize the storage allocation information provided in this document to plan the configuration of a large DS8000 storage facility in conjunction with the use of the thin provisioning facility. Lets assume the following requirements and limitations: Storage Facility configuration supports up to 1024 disk slots. Initial configuration is 128 two TB disks (see Notes at end of section). Over time, the configuration is planned to expand up 1024 two TB disks. All ranks are RAID 5. All logical volumes are fixed block. In the initial and final configuration, the user wants 32 TB of standard volumes. In the initial and final configuration, the user wants 128 TB of TSE logical volumes with a 4:1 over commit ratio. In the initial configuration the user wants 2 PB of ESE logical volumes. In the long run, the user wants about a 4:3 over-commit ratio on the ESE logical volumes. In the initial configuration, the over commit ratio can be whatever it turns out. Assume the over commit ratio of all the ESE volumes should be equivalent at any given time. All logical volumes will be one size. The overall performance of the storage facility image across the range of capacity points being considered is understood and acceptable for the set of applications intending to use this capacity.
WP101550
9/28/2009 Page 17
Assuming the disk are 90% customer usable capacity and an N+P array provide N times the disk customer usable disk capacity, the following data would apply to the disks and associated RAID 5 arrays: Calculation NC EC=NC*0.9 R1C=6*EC R2C=7*EC Value 2.0 1.8 10.6 12.6
Disk Nominal Capacity (TB) Disk Effective Capacity (TB) 4 RAID 5 6+P Real Capacity (TB) 4 RAID 5 7+P Real Capacity (TB) 4
The storage facility automatically configures spares for these disk when the RAID arrays are configured resulting in eight 6+P arrays and eight 7+P arrays. For the two configurations, the resulting arrays and capacities would be as follows: Calculation #Disks #Arrays #DA Pairs #RAID 5 6+P Arrays #RAID 5 7+P Arrays Total Real Capacity (TB) D A=D/8 P=Max(8, D/64) R1=Min(A,P*4) R2=A-R1 RC=R1*R1C + R2*R2C Initial Config 128 16 2 8 8 374.4 Final Config 1024 128 8 32 96 3110.4
The capacities consumed for the desired logical volume configurations would be as follows:
Calculation Std LV Capacity (TB) Real Cap. for Std LV (TB) SC SR = SC
Initial Config 32 32
Final Config 32 32
WP101550
9/28/2009 Page 18
TSE LV Capacity (TB) TSE LV Over Commit Repository Capacity (TB) Real Cap. For Repository (TB)1 Virt. Cap. For TSE LV (TB) Real Cap. For TSE Virt. Cap. (TB) ESE LV Capacity (TB) Virt. Cap. For ESE LV (TB) Real Cap. For ESE Virt. Cap. (TB)1 Total Virtual Capacity Configured Total Real Capacity Allocated Total Real Capacity Configured ESE Available Capacity ESE Over Commit Ratio
1
TC TOC= 4/1 RC = TC / TOC RR = RC * 1.011 TV = TC TRV = TV / 227.5555 EC EV = EC ERV = EV / 227.5555 C V = TV + EV CRA = SR + TRV + RR + ERV CR EA = CR - CRA EOC = EC / EA
128 4:1 32 32.35 128 0.56 2048 2048 9 2176 73.91 187.20 113.29 2048 : 113 = 18.08 : 1
128 4:1 32 32.35 128 0.56 2048 2048 9 2176 73.91 1555.20 1481.29 2048 : 1481 = 1.38 : 1 4:3 = 1.33:1 3731.20 4096
Total Capacity Configured Max. Capacity Allowed
C = CR + CV CMax
2363.20 4096
1. Calculations shown are for fixed block entities.
To further complete the configuration definition, we intend to divide the real and virtual capacity equally between the two servers in the storage facility image. This results in slightly more than 2 PBs of virtual capacity per side. Since we cannot exceed the 2 PB virtual capacity limit per extent pool limit, we must configure two extent pools for each server. The split between the two servers results in 16 RAID 5 6+P arrays and 48 RAID 5 7+P arrays on each server. To split up the available ranks on each server between the two extent pools, there are potentially a number of ways to divide up the capacity. In this particular example, we want to be able to reduce the ESE volume over-commit ratio consistently over time so the approach attempted here is to put all the standard and TSE
WP101550
9/28/2009 Page 19
IBM DS8000 Storage Allocation Overview logical volumes in one extent pool and then split the ESE logical volumes equally between the two pools. This means that the initial configuration will have an imbalance between the two extent pools, but capacity additions over time will be divided equally across all four extent pools (assuming that multiple of four ranks are added at any given time). For the two extent pools on each server, the following choice provides a relatively equivalent scaling of the over-commit ratio for the ESE volumes over the four extent pools:
Calculation #RAID 5 6+P Arrays per Server #RAID 5 7+P Arrays per Server R1S = R1 / 2 R2S = R2 / 2
Initial Config 4 4
Final Config 16 48
Extent Pool A #RAID 5 6+P #RAID 5 7+P Real Capacity (TB) R1a R2a CRa = R1a * R1C + R2a* R2C SRa = SR / 2 RRa = RR / 2 TVa = TV / 2 TVRa = TVR / 2 EVa = EV / 4 EVRa = EVR / 4 CVa = TVa + EVa CRAa = SRa + RRa + TVRa + EVRa EAa = CRa - CRAa EOCa = ECa / EAa = EVa / EAa Extent Pool B 2 (=R1b) 3 (= R2b + 2) 59.4 8 (=R1b) 25 (= R2b + 2) 401.4
Real Cap. for Std. LV (TB) Real Cap. for Repository (TB) TSE Virtual Capacity (TB) Real Cap. for TSE Virtual Cap. (TB) ESE Virtual Capacity (TB) Real Cap. for ESE Virtual Cap. (TB) Total Virtual Capacity Configured Total Real Capacity Allocated ESE Available Capacity ESE Over-Commit Ratio
16 16.18 64 0.28 512 2.25 576 34.71 24.69 20.73 : 1
16 16.18 64 0.28 512 2.25 576 34.71 366.69 1.40 : 1
WP101550
9/28/2009 Page 20
RAID 5 6+P RAID 5 7+P Real Capacity (TB)
R1b R2b CRb = R1b * R1C + R2b* R2C
2 1 34.2
8 23 376.2
Real Cap. for Std. LV (TB) Real Cap. for Repository (TB) TSE Virtual Capacity (TB) Real Cap. for TSE Virtual Cap. (TB) ESE Virtual Capacity (TB) Real Cap. for ESE Virtual Cap. (TB) Total Virtual Capacity Allocated Total Real Capacity Allocated ESE Available Capacity ESE Over-Commit Ratio EVb = EV / 4 EVRb = EVR / 4 CVb = TVb + EVb CRAb = SRb + RRb + TVRb + EVRb EAb = CRb - CRAb EOCb = ECb / EAb = EVb / EAb
0 0 0 0 512 2.25 512 2.25 31.59 16.03 : 1
0 0 0 0 512 2.25 512 2.25 373.95 1.37 : 1
Finally, we need to validate that the desired logical volumes can be configured without exceeding the number of logical volumes supported. The configured capacity of all logical volumes is 2 PB + 128 TB + 32 TB = 2028 TB. The maximum supported number of logical volumes limited to 65,520 and the maximum supported logical volume size is 2 TB. As such, the logical volumes sizes possible are bounded by 32 GB to 2 TB. Lets assume the user decides to configure 128 GB logical volumes. This would say that we need 256 standard logical volumes (32 TBs total), 1024 TSE logical volumes (128 TBs total), and 16K ESE logical volumes (2 PB total). Each volume type is split 50/50 between the servers. For a given server, one extent pool has all the Std LVs (128), all the TSE LVs (512), and of the ESE LVs (4K) and the other extent pool has the other of the ESE volumes (4K). Also notice that the configuration has been set up so that the capacity of the ESE volumes exposed to the attached hosts remains constant throughout the expansion of capacity on the storage facility image. As such, the configuring of the software stack to access this thin provisioned capacity may only need to be performed once Although this particular example is rather arbitrary, it demonstrates the overall techniques used in capacity planning on a DS8000 when using the variety of available storage allocation methods. Although we have attempted to minimize the number of extent pools
WP101550
9/28/2009 Page 21
IBM DS8000 Storage Allocation Overview here with the assumption that all the disk storage is homogeneous in characteristics, it is equally possible to have more types of disk storage, requiring more extent pools in the configuration, or to configure more extent pools than are absolutely necessary for whatever reason. Minimizing the number of extent pools does avoid issues with attempting to partition the available capacity between the set of configured extent pools. Note 1: In thin provisioning environment, it is likely that the user will start out with some high ratio of over commitment with the expectation that he will grow the configured capacity over time as his requirements grow, without changing the size of the thin provisioned volumes. This will tend to lead to configurations approaching 1:1 overcommit ratios in the long run. Note 2: Configuration expansion may occur over a long period of time and it is possible that improvements in disk technology or configuration capability will improve the configurable capacity of the storage subsystem yet to be configured. A more realistic example might have started this exercise with 1 TB disk (currently available) and then later planned around the existing disk technologies at the time of expansion. The use of heterogeneous disk types would have changed the spare allocation requirements and further complicated this example. Note 3: Currently only 1 TB disks are available, but 2 TB disks are on the horizon. If a long enough time line is assumed, the 2 TB disks would likely be available for part or all of the expansion phase assumed. This example chose to use 2 TB disks providing roughly 1.5 PB of real capacity and 2 PB of virtual capacity, resulting in close to a 1:1 over commit ratio so that the 4 PB limit on the storage facility and 2 PB virtual limit on the extent pool would need be considered more carefully. Using just 1 TB disks, the same ratios would be achievable with say 1 PB of real capacity and 1 PB of virtual capacity without approaching these limits; or if a larger over commit ratio were acceptable, the limits could be approached with say 1 PB of real capacity and 3 PB of virtual capacity. Note 4: In the above example, an approximation of 0.9 x nominal capacity was used for the effective disk size and the same value was used to determine rank capacities based on the number of data drives in the array. In a real example, the actual rank sizes defined in the installation planning guide should be used to determine rank capacities for a given disk family. If such information is not available, 0.9 x nominal capacity is a reasonable estimate for a SATA disk class and 0.97 x nominal capacity is a reasonable estimate for an enterprise disk class.
4.8
Extent Allocation
When multiple real ranks exist in an extent pool, there is a choice to be made about how to select extents for allocation to a logical volume, virtual storage, or a space efficient repository. The configuration interface supports an extent allocation method (EAM) attribute on logical volumes that gives the customer some options on how this operation is performed.
WP101550
9/28/2009 Page 22
IBM DS8000 Storage Allocation Overview Figure 5 shows the two extent allocation methods that are supported. In the figure, the placement of the extents on any given rank has been arbitrarily chosen to aid in the understanding of the method described. In actual implementation, an extent chosen from a given rank could be any available extent on that rank. For the purposes of extent allocation, the ranks in the extent pool are considered to be ordered. With the rotate extents EAM, the first extent allocated to the first logical volume configured is assigned to the first real rank. Successive extents allocated to this logical volume are assigned to successive ranks in the extent pool, rotating through all ranks that have available extents. When succeeding logical volumes are configured, the first extent allocated to each successive volume is assigned to the next rank following the rank that allocated the first extent of the preceding logical volume. In the case of a standard logical volume, virtual storage, or a space efficient repository, all extents are allocated at volume configuration or volume expansion time. As such, the extents are allocated in the logical order they occur on the logical volume and the rotation through the available ranks occurs in this logical order. In the case of an extent space efficient logical volume, extents are allocated in the order that they are first written. As such, extents are allocated randomly from the perspective of the logical order they occur on the logical volume, but still rotate through the available ranks as they are allocated. With the rotate volumes EAM, the first extent allocated to the first logical volume configured is assigned to the first real rank. Successive extents allocated to this logical volume are assigned to the same rank if available, or to the next successive rank in the extent pool, if not. When succeeding logical volumes are configured, the first extent allocated to each successive volume is assigned to the next rank following the rank that allocated the first extent of the preceding logical volume. Both EAMs can be specified on different logical volumes in the same extent pool. Virtual storage and space efficient repositories cannot specify an EAM, but use the rotate extents EAM implicitly. The rotate extents EAM distributes the capacity allocated to one logical volume across the available ranks so that random accesses to the volume can leverage the performance of multiple ranks. For standard logical volumes, it also rotates the first extent of each volume, which often has higher access requirements due to the placement of volume control data in this area, across the available ranks. This EAM is generally recommended because it tends to avoid hot spots on any one rank since the workload of all volumes tends to be distributed over the available ranks. The rotate volumes EAM localizes the capacity allocated to one volume on a single rank, but distributes volumes across the available ranks. This may be desirable from the perspective that the number of ranks that are included in the logical volumes failure boundary is limited.
WP101550
9/28/2009 Page 23
IBM System Storage
Extent Allocation Methods

Rotate Extents
Extents for LV Rotate through Ranks in Extent Pool First Extent of each LV Progresses through Ranks in Extent Pool
1 4 3 2 5 1 4 2 5 1 4 3 2 5 3 2 5 1 4 3
STD LVs Rotate in Logical Order (Allocated in Order) ESE LVs Rotate in Order Allocated
Rotate Volumes
Extents for LV on one rank Ranks in Extent Pool First Extent of each LV Progresses through Ranks in Extent Pool
1 2 3 4 5 1 2 3 4 5
1 2 3 4 5
1 2 3 4 5
STD and ESE LVs Rotate In order Created (Allocated in Order)
Each Logical Volume Creation is Independent can mix algorithms in Extent Pool
DS/8000 Storage Allocation 2009 IBM Corporation
Figure 5. Extent Allocation Methods
4.9 Capacity Initialization

From the hosts perspective, any capacity that is allocated to a logical volume is preinitialized. On a fixed block logical volume, any logical block which is read before it is written contains zeroes. On a CKD logical volume, any CKD logical track which is read before it written is formatted with a default record 0 which contains a count field with the physical cylinder and head (CCHH) of the logical track, record (R) =0, key length (KL) = 0, and data length (DL) = 8. The data field contains eight bytes of zeroes. On fixed block logical volumes, any real capacity allocated to the logical volume during logical volume creation, logical volume expansion, or dynamic extent allocation (on ESE logical volumes), is initialized dynamically at the time of allocation with the Quick Initialization (Quick Init) process. The capacity allocated to a fixed block volume is also initialized by Quick Init when a SCSI Format Unit command is issued. Quick Init allows the volume to be online to a host while it is being initialized. An initialization-required indication is maintained for each unit of capacity. At the time of extent allocation, all initialization-required indications associated with a given extent are set. A background process initializes un-initialized capacity units while the logical volume is online to the host, resetting the initialization-required indication as each capacity unit is processed. If a host performs a read access to an un-initialized capacity unit, one or more initialized
WP101550
9/28/2009 Page 24
IBM DS8000 Storage Allocation Overview tracks are synthesized in the read cache as required. If a host write is destaged to an uninitialized capacity unit, the host write data is merged with an initialization pattern for any parts of the capacity unit that are not included in the write data, the capacity unit is destaged, and the initialization required indication for this capacity unit is reset. On CKD logical volumes, any real capacity allocated to the logical volume during logical volume creation or logical volume expansion is initialized before it is allocated. The real extents on a rank are initialized as part of rank creation so that extents on newly created ranks can be allocated without additional processing. When CKD logical volumes are deleted, the allocated extents must be pre-initialized before they are re-allocated. On space efficient repositories, any real capacity allocated to the repository for repository metadata during repository creation is initialized as part of the creation process. On virtual storage, any real capacity allocated to the logical space during virtual storage creation or expansion is initialized after the creation process. Virtual extents in virtual storage become available for allocation as they are initialized. On space efficient (TSE and ESE) logical volumes, the release of any allocated capacity on the logical volume performs an implicit initialization of the released capacity from the host's perspective (e.g. read access to unallocated capacity causes the synthesis of initialized data). Capacity is released on ESE and TSE logical volumes if the logical volume is deleted, when the Initialize Volume function is invoked through the configuration interface, or, on a fixed block volume, when the SCSI Format Unit command is issued. Note 1: A request to configure a standard CKD logical volume fails if there are insufficient initialized real extents. A request to configure an ESE or TSE logical volume fails if there are insufficient initialized virtual extents. Note 2: The GUI transparently configures virtual storage when ESE or TSE logical volumes are created. The process includes waiting for the virtual storage to complete initialization before requesting the creation of the TSE or ESE logical volumes such that the request does not fail due to lack of initialized virtual extents. Note 3: Copy services operations can be invoked on a logical volume that is performing a Quick Init. Quick Init cannot be invoked on a logical volume that has an existing copy services relationship. Note 4: Quick Init is an improved version of the previously released FlashInit function. The prior FlashInit function did not support the invocation of copy services functions during a FlashInit.
4.10 DS8000 Copy Services

DS8000 copy services are allowed and supported on standard logical volumes for all defined usage cases. DS8000 copy services are allowed and supported on TSE logical volumes for all defined usage cases. The usage cases on TSE logical volumes are limited to operation as a FlashCopy target (Space Efficient Flash Copy), including the case of a Global Mirror
WP101550
9/28/2009 Page 25
IBM DS8000 Storage Allocation Overview tertiary volume. TSE logical volumes can be directed to release their allocated repository capacity when a FlashCopy relationship is withdrawn. Copy services are allowed, but not supported on ESE logical volumes. The customer should not initiate a copy services operation that involves an ESE logical volume. Note 1: A TSE logical volume can also be copied to a standard logical volume on the same storage facility image for the purposes of converting from a TSE to standard logical volume. Note 2: Volume expansion is not allowed on a volume with a copy services relationship.
5 Thin Provisioning Considerations

Thin provisioning implementations typically have dependencies on the software stack having certain behaviors if space efficiency is to be achieved. In the case of an implementation with a large granularity of capacity allocation, such as DS8000 Thin Provisioning, the software should store data in large contiguous regions such that the unused capacity consists primarily of large contiguous regions. Large in this case would be on the order of a number of gigabytes. The current implementation of DS8000 Thin Provisioning does not provide a mechanism to release space on less than the entire logical volume. As such, the software should tend to store data in regions that have been previously used to store data before storing data in regions that have never been previously used to avoid allocating capacity unnecessarily. Given the inability to release space, it is also desirable that the applications data tend to monotonically increase overtime. While deletion of data from the file system or database is allowed, the space consumed by this deleted data is not released. Section 5.1, "IBM AIX/JFS2 File System with DS8000 Thin Provisioning", may provide more insight into these concepts. The following information may be of use in exploiting DS8000 Thin Provisioning. To migrate data from a file system mount point that uses standard logical volumes to a mount point on a file system that uses DS8000 thin provisioned volumes, a standard file copy utility can be used. A standard full volume copy utility would typically not work since it will copy all data on the source volume to the target volume causing the target volume to be fully allocated. It may be possible to use certain full volume copy or mirroring utilities that are designed to work with space efficient storage to migrate data from standard to thin provisioned storage. Such a utility would only copy data that is actually allocated by the file system or logical volume manager from the source-volume to the spaceefficient target volume. The IBM SofTek TDMF Thin Data Copy is an example of such a utility (see Application Software).
WP101550
9/28/2009 Page 26
IBM DS8000 Storage Allocation Overview Assuming the application or file system does a good job of placing data in general, in cases where a thin provisioned mount point has more space allocated than is desired due to deletion activity, one option to reclaim space would be to create a new thin provisioned mount point and copy the data as described for converting a mount point with standard logical volumes to a mount point with thin provisioned logical volumes. To copy or backup a thin provisioned volume (in the absence of support for copy services) to a non-thin provisioned device, any backup utility can be used. Any parts of the thin provisioned volume which are not allocated appear to the backup utility as pre-initialized storage and will be handled in the same way that a non-thin provisioned logical volume would. To copy or backup data on a standard logical volume or a thin provisioned logical volume used in a file system to a thin provisioned volume (in the absence of support for copy services), release the space on the target volume, create a file system on the target volume, then copy the files from the source file system to the target file system. To restore data to a thin provisioned volume, it may be necessary to first restore the data to a standard logical volume and then copy the files from that volume to a thin provisioned volume as previously described. The need to do this depends on whether the backup/restore programs do a full volume backup or a file based backup. In general, we would expect the behavior of applications that use a file system to be determined by the file system behavior relative to thin provisioning. See section 5.2, "Thin Provisioning Software", for more information on applicable file systems. In generally, we would not expect the use of a logical volume manager to have a negative impact on thin provisioning. If the LVM allows a logical volume to be subdivided into partitions, it is advisable to create the partition boundaries on an extent boundary of the logical volume to improve the likelihood that the extent remains unallocated. Databases typically can operate with or without a file system. Without a file system, we would expect the database behavior to be the determining factor relative to thin provisioning. With a file system, we would expect the file system to be the primary factor in determining behavior relative to thin provisioning, though if the database has a characteristic of initializing all of its configured table spaces, any associated thin provisioned storage would end up fully allocated. In general, the behavioral differences between DS8000 standard logical volumes and ESE logical volumes are negligible (ignoring that copy services is currently not supported on ESE logical volumes). This might allow one to consider whether the majority of logical volumes should be configured as ESE logical volumes. What is critical in this consideration is not so much the storage allocation method (i.e. Standard vs. ESE) but rather the degree to which any ESE logical volumes are over committed. A conservative approach might be to use all ESE logical volumes, assume a 1:1 over commit ratio initially, and monitor what storage remains unallocated. Having done this, the user can have a better feel for what applications tend to under
WP101550
9/28/2009 Page 27
IBM DS8000 Storage Allocation Overview utilize their available capacity and to what degree, allowing a better projection of how much of an over commitment ratio is sustainable. For any ESE logical volumes that are over committed, the customer should have an understanding of what impact running out of space might have on their environment and what actions will need to be done to recover from the situation. The initial result of blocking write access to unallocated extents on ESE logical volumes when there is no available space typically will cause any application detecting a write failure to terminate. The ability to restore normal operation will typically require either acquiring more capacity or freeing up allocated space by releasing all space on one or more ESE logical volumes or by deleting volumes. For some applications, standard logical volumes may be the correct choice to avoid any risk of running out of space. The granularity of the DS8000 allocation unit relative to whatever metadata the file system creates when it is established should be kept in mind. In the JFS2 example described in section 5.1, "IBM AIX/JFS2 File System with DS8000 Thin Provisioning", the configuration of the volume group and file system created metadata in three places resulting in the allocation of three 1 GB extents. With a 100 GB file system, this is just a 3% initial allocation. With a 10 GB file system, it could have been a 30% initial allocation.
5.1 IBM AIX/JFS2 File System with DS8000 Thin Provisioning

This section discusses some results from testing the JFS2 file system on AIX with DS80000 Thin Provisioning. On the IBM AIX operating system, the logical volume manager provides the ability to create a volume group (VG). Each volume group is configured with one or more physical volumes (PVs). The physical volumes are divided into one or more physical partitions (PPs) that are fixed in size for a given volume group. The physical partitions are allocated to logical partitions (LPs) of a logical volume (LV). Each logical partition has at least one physical partition allocated. Up to two additional physical partitions are allocated to a logical partition, one for each mirrored copy that the logical volume has configured. The following links provides more information on AIX's logical volume manager: http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.a ix.cmds/doc/aixcmds3/lspv.htm The size of the LPs and PPs is limited to an integral number of megabytes (MiB) such that the integer is a power of 2. The number of PPs in a VG depends whether it is configured as a normal, big, or scalable volume groups. In the following discussion, we used a big VG which is limited to 128 x 1016 PPs in the VG. The number of LVs is limited to 512. The number of PVs is limited to 128 and the number of PPs on a PV is limited to 1016, by default. The number of PPs per PV can be increased by a factor of N while at the same time reducing the number of PVs by a factor of N (maximum number of PVs in the volume group remains constant). The Journal File System (JFS) and Enhanced Journal File System (JFS2) are part of the base IBM AIX operating system. JFS2 was introduced in AIX 5.1 and supports 64 bit
WP101550
9/28/2009 Page 28
IBM DS8000 Storage Allocation Overview kernels. The file system is created in a volume group and by default uses two LVs, one for a file and one for the file system data. Typically, the log file is configured with a single LP, while the file system LV can have one or more LPs. The log file can also be configured to be placed inline within the file system LV. Multiple file systems can share a common log file, or a common pair of log files, which can be resized as the file system size grows. The file system size can be between 16 MB and 32 TB with a maximum file size of 16 TB. The file system LV can also be resized by the user as needed. The file system can be defined to use either a 512, 1K, 2K or 4K byte block size to allocate space, with 4K bytes being the default size. A larger block size reduces fragmentation, allocation frequency, and allocation map structures while a smaller block size may waste less space. The JFS2 file system divides the file system space into up to 128 equal sized allocation groups that are a minimum of 32 MBs in size (last allocation group may not be full size). The file system distributes data across the allocations groups under some situations to improve localization of data which is likely to be accessed concurrently or sequentially. One design point of this file system is that it avoids using an unused allocation group until all active allocation groups have collectively less than one GB of free space left. As will be seen by the subsequent results, this behavior works well with the DS8000 Thin Provisioning feature. A few words on the overlap between DS8000 and AIX terminology may save some confusion: DS8000 Terminology: DS8000 configures physical disks into ranks and ranks into extent pools which contain extents that are allocated to logical volumes that are made accessible to open systems hosts through a list of logical volumes called a volume. AIX Terminology: AIX configures physical volumes into volume groups which contain physical partitions that are allocated to logical partitions on logical volumes that are used by applications such as file systems and data bases. Note that the logical volumes on the DS8000 are the physical volumes on AIX. Also the term volume group has two different meanings depending on context. In the subsequent discussion, AIX terminology will be used. In testing JFS2 with DS8000 thin provisioning, our servers are running AIX version 6.1.2.0. We chose to use a 128 GB physical volume on the DS8000 and a 1 GB physical partition size in the AIX volume group. The intent of this choice was to provide JFS2 with roughly 128 one GB allocation groups so that we could determine whether it was spreading its data over the allocation groups by monitoring the amount of storage allocation on the DS8000 volume. We also intended that the DS8000 physical volume should be expandable to its 2 TB maximum such that we wanted to be able to allow 2048 PPs potentially on the PV. Also considering that we might want the file system to expand to its 32 TB potential, we defined the VG with a factor of 4 such that we could have 4x1016 = 4064 PPs per PV and still allow 128/4 = 32 PVs in the VG. We configured the log in a logical volume separately from the file system logical volume. We did not test
WP101550
9/28/2009 Page 29
IBM DS8000 Storage Allocation Overview the in-band log option, but our understanding is that the in-band log is placed at the end of the file system logical volume and that it is relocated when the file system is expanded, potentially causing additional space allocations beyond what we describe subsequently. We also needed to disable the write cache on JFS2 (-o dio flag on mount command) for this testing because we wanted any writes done by the test case to be synchronously written to the DS8000 volume so that the data collected on the file system and DS8000 would be consistent at any given point in time. This is not recommended in general since the JFS2 write caching typically provides better performance for most applications. The following AIX commands were used to create the volume group and file system: mkvg -f -n -B -t 4 -s 1024 -y vgshrk1 hdisk1 # make volume group vgshrk1 crfs -v jfs2 -g vgshrk1 -a size=264241152 -m /shrk1 -A no -p rw -t no -u shark # create file system at /shrk1 mount -o dio /shrk1 # mount file system at /shrk1 After creating a volume group with just one 128 GB PV, we see that the volume group allocates some space for metadata, such that there is slightly less than 128 GBs of capacity available to create PPs. Given the 1 GB PP size, the volume group ends up with only 127 PPs and the DS8000 volume has one real extent allocated. After creating the file system, the log file LV takes one PP and the remaining 126 PPs were configured in the file system LV with a size of 126 GB (size on crfs command above is in 512-byte blocks) and the DS8000 volume has three real extents allocated. Thus the configuring the volume group and file system with no files has resulted in an initial storage allocation of 3/128 = 2.3%. Note that this does not mean that 2.3% of the physical has been used for metadata. It does mean that 3 of the 128 extents on the physical volume have been written to. Also we have explicitly configured the file system with 126 MB, so in that sense, we have lost the capacity of two PPs on the PV. We also point out that it is possible to use a smaller PP size with the result that the overhead of the volume group metadata and the log logical volume is smaller. In other words, for any given PP size, one PP is lost due to volume group metadata and one PP is lost for the log logical volume. The remaining PPs are available for the file system. The choice of the PP size also affects the maximum size of the PVs and ultimately maximum capacity that can be configured on the file system's LVs. In this test, the only LVs on the thin provisioned PV were the file system and the file system log. We would expect that placing LVs for other applications on the same PV could have a negative impact on the space efficiency of the thin provisioning. In our testing, we looked at the effect of expanding a DS8000 volume. In the test expanded a 128 GB volume to 256, 512, 1024 and 2048 GB, telling the volume group to detect the change on the physical volume after each expansion. No additional extents were allocated on the physical volume and the total number of PPs in the VG increased from 127 to 255, 511, 1023, and 2047, respectively. We also looked at the result of configuring 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, and 2046 GB file systems on the above 2048 GB physical volume with the result that only three extents were allocated on the DS8000 volume independently of the initial size of the file system. We also looked at
WP101550
9/28/2009 Page 30
IBM DS8000 Storage Allocation Overview the result of configuring a 1 GB file system and then increasing the size to 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, and 2046 GB. With each increase in file system size, one additional extent was allocated on the DS8000 volume independently of the expanded size that was chosen. The AIX commands used for this were: dscli chfbvol -cap #extents -quiet 2200 chvg -g # Expand DS8000 Volume 2200 # VG detects any changes to PV sizes # VG vgshrk1 chlv -m 2048 $lv chfs -a size=#blocks # Set maximum size of LV $lv # to 2048 PPs = 2 TB with 1 GB PP # Change FS Size
lsvg -l vgshrk1 | grep /shrk1 | read lv other # Find the one file system LV in
In testing the storage allocation behavior relative to the amount of data stored in the file system, we created a 128 KB file in the file system and copied it into additional files using the cp command in a korn shell script. The JFS2 file system algorithm for distributing data between active allocation groups has dependencies on the number of directories configured in the root mount point and whether there is more than one i-node in the directory (32 files per i-node), In our testing, we established two basic patterns for filling the file system: Pattern 1: Fill the file system from 0 to 100%. Pattern 2: File Names were alternated between A and B in each directory Fill the file system from 0 to 50% Delete 25% of data by deleting all B Files Fill the file system from 25 to 75% Delete 25% of data by deleting all B Files Fill the file system from 50% to 100% For each pattern we used three different directory structures: Directory Structure 1: 1 Root Directory 0 Child Directories 1 Total Directory 1,032,192 Files per Directory (126GB) 1,032,192 Files Total (126 GB)
WP101550
9/28/2009 Page 31
IBM DS8000 Storage Allocation Overview Directory Structure 2: 1 Root Directory 126 Child Directories per Root Directory - 6 levels, 2 children per parent 127 Total Directories 8128 Files per Directory (1016 GB) 1,032,256 Files in Total (126GB) Directory Structure 3: 129 Root Directories, 126 Child Directories - 6 levels, 2 children per parent 16383 Total Directories 64 Files per Directory (8 MB) 1,032,256 Files in Total (126GB) (254 directories empty or partially full) The expectation is that somewhat less than the total files indicated would fit in the file system since some of the capacity of the file system is required to store metadata to manage the location of data within the file system. The test cases were structured to collect data roughly four times per GB. In the directory structure 1 case, data was collected after each 2048 files (256 MB) written. In directory structure 2, data was collected after 2032 files were written (254 MB) providing four samples per directory. In directory structure 3, data was collected after each written 2048 files (256 MB) written, but in this case, the 2048 files consisted of 64 files written to 32 directories, all of which were in different root directory trees. For all patterns and directory structures (6 permutations), we ran the test writing all files serially, stopping the test on the first file that detected a copy error as a result of the file system filling up. And then finally for directory structures 2 and 3 with both patterns (4 permutations), we ran the test cases with all files for a given data sample being written in parallel by independent background threads, stopping the test on the first sample that any file detected a copy error. In all these tests, the results for characteristically the same (i.e. they look virtually identical). The results for patterns 1 and 2 with directory structure 3 and concurrent data transfer, which was the most aggressive test case of this set is shown for the two patterns in Figures 6 and 7, respectively. The initial data point 0 is with only the source data set created in the file system (and is the same as when there was no data in the file system). The file system %usage data is based on the %Used value reported to a df command for /shrk1. The storage %allocation data is based on the realextents value reported by the dscli showfbvol command divided by 128 (i.e. the percentage of total extents allocated on the DS8000 volume). As shown in Figure 6, the storage %allocation closely tracks the file system %usage for monotonically increasing data. As can be seen in Figure 7, once space is allocated on the logical volume, the deletion of data from the file system does not release any of the previously allocated data. What is important though is that, as the file system is again filled up with data to the level that matches the storage allocation after each deletion, no
WP101550
9/28/2009 Page 32
IBM DS8000 Storage Allocation Overview additional space was allocated indicating that the file system reused the previously allocated space on the volume to store new data before accessing unallocated space. Given the algorithm used for using new allocation groups, the test results are as expected for this file system. We would expect that JFS2 running on AIX, and any application which runs using this file system would be well behaved for DS8000 thin provisioning relative to data placement and storage allocation on a DS8000 thin provisioned volume.
File System Usage and Storage Allocation

128 KB Files, 129 Root Directories, 16383 Total Directories, Concurrent Copies
100% 80% 60% 40% 20% 0% 0 100 200 300 400 500 600
Samples
FS %Usage
Storage %Alloc
Figure 6. AIX with JFS2 File System 128 KB Files Fill 0-100%
WP101550
9/28/2009 Page 33
File System Usage and Storage Allocation

128 KB Files, 129 Root Directories, 16383 Total Directories, Concurrent Copies
100% 80% 60% 40% 20% 0% 0 200 400 600 800
Samples
FS %Usage
Storage %Alloc
Figure 7. AIX with JFS2 File System 128 KB Files 0-100% with 25% Deletes Although DS8000 thin provisioning does not provide an interface to release less than the full volume's space allocation, the AIX logical volume manager provides a number of mechanisms to relocate data. We exploited these capabilities to release space from a file system while it was online. In a volume group with 1 GB PPs and a single 128 GB thin provisioned physical volume, we created a 16 GB JFS2 file system and filled it to 99% usage with sixty-three 256 MB files. The associated DS8000 volume had a resulting space allocation of 19 extents. Subsequently we deleted 38 files producing a 40% usage in the file system. JFS2 supports reducing the file system by an integral number of PPs provided that the data within the file system will fit in the requested size. In this case, requested a size of 8 GB with the result that the file system LV was reduced from 16 PPs to 8 PPs with a 79% utilization. In order to release the space on the physical volume after releasing the logical volumes unused LPs, we added a second physical volume to the volume group, used the logical volume manager to migrate active PPs on the original physical volume to the new physical volume, and then removed the original physical volume from the volume group. In the process of migrating the physical volume's data, only the allocated PPs on the PV are copied resulting in only 11 extents being allocated on the second DS8000 volume. Finally, once the original physical volume was removed from the volume group, we could release the space allocation on the DS8000 volume. The AIX commands used in the process were:
WP101550
9/28/2009 Page 34
IBM DS8000 Storage Allocation Overview mkvg -f -n -B -t 4 -s 1024 -y vgshrk1 hdisk1 # create volume group
crfs -v jfs2 -g vgshrk1 -a size=264241152 -m /shrk1 -A no -p rw -t no -u shark # create file system /shrk1 chfs -a size=x /shrk1 extendvg vgshrk1 hdisk2 migratepv hdisk1 hdisk2 reducevg vgshrk1 hdisk1 dscli initfbvol 2200 # change (reduce) size of file system to x blocks # Add hdisk2 to volume group vgshrk1 # Move LV data on hdisk1 to hdisk 2 # remove hdisk 1 from volume group vgshrk1 # Release space on DSVolume 2200 (hdisk1)
In using the above methodology, be aware that the migratepv command creates some amount of work on the system to mirror the PPs as part of migrating the PV's data. This workload may affect system performance and is perhaps best done in a non-peak load window. A smaller PPs size is probably also advisable to reduce potential resynchronization actions while establishing mirrors for each PP. If the size of the file system is to be increased to some larger size after reducing the size, it is probably advisable to do this immediately after reducing the size to avoid the possibility of running out of space. As previously discussed, the expansion will probably result in allocating another PP, but this cost will be incurred whether it is done immediately or later. Increasing the size should not result in allocating any other additional PVs unless the amount of data in the file system is increasing. Another consideration is that the user must have enough capacity on the DS8000 to support the storage allocation required by original file system as well as the storage allocation required to create the reduced allocation copy for the duration of the migration before space is released. It may be desirable to maintain a pair of DS8000 thin provisioned volumes for use with a given volume group to facilitate swapping the active physical volume out periodically to release space. The user should be particularly careful in releasing space on DS8000 volume that the correct volume is released. Releasing space results in a complete re-initialization of the physical volume (i.e. any existing data on the volume is lost). Releasing space on an hdisk that is currently in a volume group is not recommended. Relative to configuring a maximum sized JFS2 file system, the volume group can be configured with sixteen 2 TB thin provisioned physical volumes to create the required capacity for a 32 TB file system. To support release of space, another 16 thin provisioned volumes can be created to allow the data to be migrated to the new physical volumes. The logical volume manager also provides various mechanisms to migrate logical volumes or to create copies or mirrors of logical volumes. To the extent these mechanism can be used to copy only the PVs allocated to a given logical volume to a specific thin provisioned physical volume, the resulting copies or mirrors should be space efficient. In these scenarios, the user should release space on a physical volume before it is added to the volume group, and then, subsequent to adding the physical volume to the volume group, create the desired copies or mirrors on a given thin provisioned physical volume. Also any if the source copy is a file system that supports reducing its size such as JFS2,
WP101550
9/28/2009 Page 35
IBM DS8000 Storage Allocation Overview the size of the file system should be reduced to release as much space as possible before creating a copy or a mirror on a thin provisioned volume.
5.2 Thin Provisioning Software

The following software has had some evaluation by IBM and is believed to be well behaved for DS8000 thin provisioning: IBM JFS2 File System on AIX The following additional software has had less evaluation, but is believed to be well behaved for DS8000 thin provisioning: IBM JFS (JFS2) File System on Linux Veritas File System (VxFS) on HP, SUN, Linux, and AIX HP/UX JFS (VxFS) ReiserFS on Linux Softek TDMF for Windows Thin Data Copy Option
The following software has had less evaluation, but is believed to have the described characteristics that are not ideal for DS8000 thin provisioning: Windows NTFS With file deletion, does not prefer previously used space for new data (e.g. will wrap the volume typically with new allocations, eventually fully allocating all space). Oracle OCFS2 on Linux Grows space allocation faster than file system usage. Ext 2 on Linux Large initial storage allocation when create file system.
The following software has had less evaluation, but without any special customization which might be available, is believed to have characteristics that do not result reasonable in thin provisioning with DS8000 thin provisioning: IBM GPFS on AIX, Linux HP/UX HFS Solaris UFS SGI XFS Episode DFS Ext3 on Linux
5.3 DS8000 Thin Provisioning and Quick Initialization Performance

Hardware Configuration The tests described in this section used the following hardware configuration: The disk system was a DS8300 Turbo. The measurements were done with Fixed Block (FB) formatted RAID-5 arrays. A total of 64 146GB/15k RPM disks were used (60 active and 4 spares).
WP101550
9/28/2009 Page 36
IBM DS8000 Storage Allocation Overview Host workloads were run on an AIX host (AIX 5.3.0.40) with 8 2Gb Fibre Channels.
Results To enable Thin Provisioning with minimal performance impact, a more efficient volume initialization method referred to as Quick Initialization (QI) was implemented. QI replaces the prior volume initialization method referred to as FlashInit (FI). A performance comparison between QI and FI is shown in Figure 8. In this example, it took QI only 6 minutes while FI took 16 minutes to initialize a 250 GB volume. Thus, QI was 2.6 times faster than FI in this test. Since QI is similar to FI or FlashCopy with background copy in terms of their use of system resources, it is recommended that standard logical volumes be created or expanded when workloads to existing volumes that share disks or device adapters are light. This will minimize any impact to host I/O to existing volumes.
Duration (minute)
20 15 10 5 0 QI FI
Figure 8. Volume Initialization 250GB - 8 ranks, 2 DAs, 146GB 15K
QI is invoked to initialize each real extent that is newly allocated to a fixed block logical volume. This means that whenever a standard logical volume is created or expanded, or whenever an extent of a thinly provisioned volume is first written, the 1 GB of space in each newly allocated real extent is initialized via QI. One typical case that will cause space to be allocated for ESE logical volumes is a sequential write stream. For example, a sequential write task is normally invoked when copying or creating a new file on a volume. Figure 9 shows sequential write performance for both standard and ESE logical volumes, with or without QI being active. As seen in the figure, QI had a very minimal performance impact on sequential writes for either Standard or ESE volumes. Whether QI is active or QI is completed, the sequential write performance of ESE logical volumes was the same as that of standard logical volumes.
WP101550
9/28/2009 Page 37
-2% due to QI activity
600 500
MB/s
400 300 200 100 0

newly allocated (QI Active)
Standard Volume
previously allocated (QI Completed)

ESE Volume
Figure 9. 64K Sequential Write to Standard and ESE volumes 8 ranks, 2 DAs, 146GB 15K
Figure 10 shows a performance comparison of a random read/write workload to Standard and ESE logical volumes when space has been allocated and QI has completed. A database like workload called Database Open (DBO) was used for the test. This workload uses 4 KB transfers, 70% reads, 30% writes and 50% cache hits. As shown in Figure 10, there is no performance difference between Standard and ESE volumes for a heavy DBO workload where system resources available are heavily utilized.
WP101550
9/28/2009 Page 38
Same performance
30 25
KIO/s
20 15 10 5 0
Standard Volume ESE Volume (previouly allocated)
Figure 10 Heavy DBO Workload - 8 ranks, 2 DAs, 146GB 15K
The measurement results shown here support the conclusion that, in general, the performance of ESE logical volumes is equivalent to that of standard logical volumes. Thus clients may consider introducing ESE volumes for a broad class of applications and be confident that thin provisioning will not adversely affect their performance.
WP101550
9/28/2009 Page 39

DS8000 Storage Allocation Overview V1.0a

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

DS8000 Storage Allocation Overview V1.0a

Caricato da

Copyright:

Formati disponibili

IBM DS8000 Storage Allocation Overview

IBM DS8000 Storage Allocation Overview Including Thin Provisioning

Version 1.0a September 28, 2009

IBM DS8000 Storage Allocation Overview

IBM DS8000 Storage Allocation Overview

IBM DS8000 Storage Allocation Overview

3 Storage Allocation Concepts

4 Storage Allocation on DS8000

4.1 Standard Logical Volumes

IBM DS8000 Storage Allocation Overview

Standard Logical Volumes

Extent Pool Standard LV

Each real extent contains extent data And extent metadata

Each LV extent is mapped to a real extent on a rank

= 1024 MB Extent Data (Customer) 4.5 MB Extent Metadata (+0.439%)