Ds8000 Ese Pool

Front cover
DS8000 Thin Provisioning
Avoid allocating unused capacity
Read about new ESE repository

capability and new controls
Understand applications and
OS implications
Bert Dufrasne
Peter Kimmel
Bruce Wilson
ibm.com/redbooks
Redpaper
International Technical Support Organization

July 2014
REDP-4554-01
Note: Before using this information and the product it supports, read the information in Notices on page v.
Second Edition (July 2014)

This edition applies to the IBM DS8870 with Licensed Machine Code (LMC) 7.7.20.xx.xx (bundle version
87.20.xxx.xx) or later.
Copyright International Business Machines Corporation 2014.

Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule
Contract with IBM Corp.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .v
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Now you can become a published author, too! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Stay connected to IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
June 2014, Second Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
Chapter 1. Thin provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1 General description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1 Thin provisioning model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.2 Thin provisioning usage examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 DS8000-specific implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.1 Track space-efficient (TSE) volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.2 Extent space-efficient (ESE) volumes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
2
3
4
5
5
5
6
Chapter 2. Planning considerations and guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1 General considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1 Thin provisioning benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.2 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.3 Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.4 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.5 Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Planning steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1 Planning examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Chapter 3. Space-efficient volumes in the DS8000 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1 DS8000 logical volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Track space-efficient volumes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Repository for track space-efficient logical volumes . . . . . . . . . . . . . . . . . . . . . . .
3.3 ESE logical volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2 Optional ESE repository for ESE logical volumes. . . . . . . . . . . . . . . . . . . . . . . . .
3.3.3 Capacity allocation for ESE volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.4 Out-of-space condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.5 Volume creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.6 Releasing space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.7 Migration considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.8 Performance considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
18
18
19
21
21
21
27
28
31
32
32
32
Chapter 4. Enabling thin provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.1 Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Activation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Enabling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
36
36
38
Copyright IBM Corp. 2014. All rights reserved.
iii
4.4 Disabling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Chapter 5. DS GUI and DS CLI support for thin provisioning . . . . . . . . . . . . . . . . . . . .
5.1 DS GUI and DS CLI support for thin provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 DS Storage Manager GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 DS CLI commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4 Logical configuration process for ESE volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4.1 Configuring ESE volumes with the DS GUI illustrated . . . . . . . . . . . . . . . . . . . . .
5.4.2 Configuring ESE volumes with the DS CLI illustrated. . . . . . . . . . . . . . . . . . . . . .
41
42
42
47
57
58
66
Chapter 6. Managing and monitoring thin-provisioned volumes . . . . . . . . . . . . . . . . .

6.1 Management and monitoring capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.1 Options to reserve space and buffer capacity. . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.2 Options to set thresholds and receive warnings . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.3 SNMP trap: Extent pool threshold. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.4 Managing out-of-space situations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
76
76
76
78
79
Chapter 7. Host considerations and migration to ESE volumes . . . . . . . . . . . . . . . . . 81

7.1 ESE volumes in IBM AIX with JFS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.1.1 Introduction to AIX JFS2 concepts and terminology . . . . . . . . . . . . . . . . . . . . . . . 82
7.1.2 Test results on AIX with JFS2 File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.2 Migration considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.2.1 Thin provisioning usage cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.2.2 Migration tools and utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.3 Examples of migrating to ESE volumes on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.3.1 Softek TDMF product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.3.2 Typical scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
7.3.3 Migration from standard volumes to ESE volumes . . . . . . . . . . . . . . . . . . . . . . . . 90
7.3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
7.4 Thin provisioning software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How to get Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iv
105
105
105
105
105
106
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area. Any
reference to an IBM product, program, or service is not intended to state or imply that only that IBM product,
program, or service may be used. Any functionally equivalent product, program, or service that does not
infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to
evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document. The
furnishing of this document does not grant you any license to these patents. You can send license inquiries, in
writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of
express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may make
improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time
without notice.
Any references in this information to non-IBM websites are provided for convenience only and do not in any
manner serve as an endorsement of those websites. The materials at those websites are not part of the
materials for this IBM product and use of those websites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring
any obligation to you.
Any performance data contained herein was determined in a controlled environment. Therefore, the results
obtained in other operating environments may vary significantly. Some measurements may have been made
on development-level systems and there is no guarantee that these measurements will be the same on
generally available systems. Furthermore, some measurements may have been estimated through
extrapolation. Actual results may vary. Users of this document should verify the applicable data for their
specific environment.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm the
accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the
capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the sample
programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore,
cannot guarantee or imply reliability, serviceability, or function of these programs.
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines
Corporation in the United States, other countries, or both. These and other IBM trademarked terms are
marked on their first occurrence in this information with the appropriate symbol ( or ), indicating US
registered or common law trademarks owned by IBM at the time this information was published. Such
trademarks may also be registered or common law trademarks in other countries. A current list of IBM
trademarks is available on the web at http://www.ibm.com/legal/copytrade.shtml
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
AIX
DS8000
Enterprise Storage Server
FlashCopy
GPFS
IBM
Parallel Sysplex
Redbooks
Redpaper
Redbooks (logo)
System Storage
System z
TDMF
Tivoli
Tivoli Enterprise Console
z/OS
The following terms are trademarks of other companies:

Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Microsoft, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States,
other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Other company, product, or service names may be trademarks or service marks of others.
vi
Preface
Ever-increasing storage demands have a negative impact on an organizations IT budget and
complicate the overall storage infrastructure and management. Companies are looking at
ways to use their storage resources more efficiently.
Thin provisioning can help by reducing the amount of unused storage typically allocated to
applications or users. Thin provisioning, now available for the IBM DS8000, defers the
allocation of actual space on the storage system until the time that the data must effectively
be written to disk.
This IBM Redpaper publication provides an overall understanding of how thin provisioning
works on the DS8000. It provides insights into the functional design and its implementation on
the DS8000 and contains illustrations for the configuration of thin-provisioned volumes from
either the DS GUI or the DS CLI.
This edition reflects the capability to define an extent space-efficient (ESE) repository, which
was introduced with the DS8870 Release 7.2 firmware.
This paper also includes considerations that will help you decide which applications will
effectively benefit from thin provisioning. It takes you through scenarios and utilities for
migrating from standard volumes to thin-provisioned volumes.
Authors
This paper was produced by a team of specialists from around the world working at the
International Technical Support Organization, San Jose Center.
Bert Dufrasne is an IBM Certified IT Specialist and Project Leader for IBM System Storage
disk products at the ITSO, San Jose Center. He has worked at IBM in various IT areas. He
has written many IBM Redbooks publications and has developed and taught technical
workshops. Before joining the ITSO, he worked for IBM Global Services as an Application
Architect. He holds a Masters degree in Electrical Engineering.
Peter Kimmel is an IT Specialist and Advanced Technical Support team lead of the
Enterprise Disk Solutions team at the ESCC in Mainz, Germany. He joined IBM Storage in
1999 and since then worked with all the various IBM Enterprise Storage Server (ESS) and
DS8000 generations, with a focus on architecture and performance. He has been involved in
the Early Shipment Program (ESP) of these early installations and all current installations,
and co-authored several DS8000 IBM Redbooks publications. Peter holds a Diploma (MSc)
degree in Physics from the University of Kaiserslautern.
Bruce Wilson is a Senior Education Specialist with ITS in IBM Canada. He has worked with
IBM for 32 years, with the first 10 years in the field servicing mainframe servers and various
storage products. For the last 22 years, he has instructed IBM service representatives on the
System z server, IBM Parallel Sysplex, and disk and tape hardware. Bruce has
co-authored two previous Redbooks publications dealing with hardware configuration
definition (HCD) and SAN products.
vii
For their input and advice during the preparation of this paper:
Rick Ripberger, Dale H. Anderson
IBM US
Now you can become a published author, too!

Heres an opportunity to spotlight your skills, grow your career, and become a published
authorall at the same time! Join an ITSO residency project and help write a book in your
area of expertise, while honing your experience using leading-edge technologies. Your efforts
will help to increase product acceptance and customer satisfaction, as you expand your
network of technical contacts and relationships. Residencies run from two to six weeks in
length, and you can participate either in person or as a remote resident working from your
home base.
Find out more about the residency program, browse the residency index, and apply online at:
http://www.ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us!
We want our papers to be as helpful as possible. Send us your comments about this paper or
other IBM Redbooks publications in one of the following ways:
Use the online Contact us review Redbooks form found at:
http://www.ibm.com/redbooks
Send your comments in an email to:
redbooks@us.ibm.com
Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400
Stay connected to IBM Redbooks publications

Find us on Facebook:
http://www.facebook.com/IBMRedbooks
Follow us on Twitter:
http://twitter.com/ibmredbooks
Look for us on LinkedIn:
http://www.linkedin.com/groups?home=&gid=2130806
viii
Explore new Redbooks publications, residencies, and workshops with the IBM Redbooks
weekly newsletter:
https://www.redbooks.ibm.com/Redbooks.nsf/subscribe?OpenForm
Stay current on recent Redbooks publications with RSS Feeds:
http://www.redbooks.ibm.com/rss.html
Preface
ix
Summary of changes
This section describes the technical changes made in this edition of the paper and in previous
editions. This edition might also include minor corrections and editorial changes that are not
identified.
Summary of Changes
for DS8000 Thin Provisioning
as created or updated on July 2, 2014.
July 2014, Second Edition

This revision reflects the addition, deletion, or modification of new and changed information
described below.
New or changed information

Added support for the extent space-efficient (ESE) repository, introduced with the
IBM DS8870 with Licensed Machine Code (LMC) 7.7.20.xx.xx. The ESE repository is
described in Chapter 3, Space-efficient volumes in the DS8000 on page 17.
Updated Chapter 5, DS GUI and DS CLI support for thin provisioning on page 41 to
include new controls for DSCLI commands and support for the ESE repository.
xi
xii
Chapter 1.
Thin provisioning
This chapter introduces the concepts and terminology related to thin provisioning in general.
It also includes a brief overview of the DS8000 thin provisioning implementation.
1.1 General description

Thin provisioning applies to shared storage environments. The concept of thin provisioning is
to allocate storage (blocks or other elements of storage capacity) when application data is
effectively written to a host-attached volume. This is the fundamental difference with the
traditional, fully provisioned volume, where the volume capacity is entirely allocated at the
time the volume is created. In this case, the host to which the fully provisioned volume is
attached owns the full capacity, therefore consuming unused storage in the back-end system.
Figure 1-1 illustrates the general differences between full provisioning and thin provisioning.
Server
Storage
Full Provisioning
Real capacity
Real capacity
Used
capacity
Thin Provisioning
Virtual capacity
Used
capacity
Capacity
Pool
Allocates on
write
Used
capacity
Figure 1-1 General differences between full provisioning and thin provisioning
A volume supporting thin provisioning is referred to as a space-efficient volume. At the time

the volume is created, real capacity as required for metadata only is physically allocated. The
DS8000 uses specific metadata to manage and determine when capacity must be allocated
for write operations.
The volume is created with the full capacity requested by the user, but because the allocation
will only take place with the first host write to the volume, this capacity is virtual. The sum of
all space-efficient volume capacity represents the storage subsystem virtual capacity.
When a space-efficient volume is assigned to a host, the host sees the whole (virtual)
capacity of the volume, as though it were a fully provisioned volume. All I/O activities
performed by the storage subsystem to allocate space when needed are fully transparent to
the host.
The amount of real capacity in the storage subsystem is shared between all space-efficient
volumes. The amount of real capacity is by definition less than the total virtual capacity. The
ratio between virtual capacity and real capacity represents the storage oversubscription or
storage over-commitment.
Thin provisioning allows a more efficient capacity use in the storage subsystem. The
automated capacity allocation (when required by applications) facilitates capacity
management, as well. Capacity monitoring is still necessary, but can now be changed from a
volume-based tracking, which can only be done on a per server basis, to the back-end
storage subsystem, where the overall view of virtual capacity and real capacity allocation is
available.
1.1.1 Thin provisioning model

Figure 1-2 illustrates the thin provisioning model of the DS8000, independent of any specific
host platform. We explain the elements of this common model in the sections that follow the
figure.
Virtual capacity pool
Write request
comes to the
space efficient
volume
Volumes with
user requested
capacity are
created from the
virtual capacity
pool
Capacity is
allocated prior
to the write
Real capacity pool
Figure 1-2 Common model of DS8000 thin provisioning
Virtual capacity pool

The virtual capacity pool is the container from which host volumes will be created. These
volumes are designated as space-efficient volumes (see description below). There is no real
physical capacity in the virtual capacity pool. The capacity specified with each space-efficient
volume is taken from that pool. You can create as many space-efficient volumes as free
virtual capacity is available.
Real capacity pool

The real capacity pool is a defined area of physical capacity in the DS8000, and is the
reservoir for physical capacity allocation when it is requested. When capacity allocation takes
place, each allocation of real capacity is mapped to the space-efficient volume.
Chapter 1. Thin provisioning
Space-efficient volumes
Space-efficient volumes are usable volumes that can be assigned to any hosts. These
volumes do not have any physical capacity (except for their required metadata) when initially
created. With the first write operation to the volume, real capacity from the real capacity pool
will be allocated to the volume.
1.1.2 Thin provisioning usage examples

This section provides some typical usage examples of thin-provisioned volumes.
Thin provisioning for user data

As a simple example, consider typical user data in a business environment. Such data is
normally the same kind for all users and might consist of local mail replica, cached data from
web browsers, or other application data commonly used by users in a business environment.
In addition, most users have similar capacity requirements for this type of data. However,
some users can also have specific applications with different capacity requirements. For
example, users who are working most of the time with documents, spreadsheets, and
presentations require less capacity than those working with images, other multimedia data, or
other binary and scientific data.
Assuming that no user is requesting more than 10 GB of data and that the average of
effectively used data is below 6 GB per user, the storage administrator can decide to allocate
10 GB of virtual capacity for each user (as thin-provisioned volumes). However, in the
back-end storage, the real capacity per user only amounts to 6 GB. If we assume 100 users,
this means that the virtual capacity is 1 TB, but only 600 GB of real capacity is available in the
storage subsystem. This is a valid approach only because the administrator knows from
previous observations that not all users will request the whole amount of physical capacity at
the same time. Some will only request 4 GB or less, some might request the whole 10 GB.
But the assumption remains that on average they all request no more than 6 GB of real
capacity.
It remains the responsibility of the storage administrator to monitor the allocation of real
capacity to avoid any out-of-storage condition.
Thin provisioning in data centers

In data centers, a shared storage infrastructure provides storage for many different
applications running on different servers. The initial storage capacity for those servers has
been requested usually during their deployment phase. The requested capacity is most likely
a combination of the initial required storage and an estimation of the growth over the
estimated application lifetime.
Looking across all applications in a data center with focus on their storage capacity demand
over time, experience has shown that some applications grow quite fast. However, other
applications have almost no change in storage need, or do not even fully use their assigned
initial capacity.
From the overall storage management point of view, this circumstance offers the opportunity
to improve the use of the shared storage capacity. A policy can be established where
assigned but unused capacity can be reassigned to applications that exhibit a more dynamic
storage demand. To allow redistribution of capacity in the storage subsystem, the storage
allocation must be separated from the storage configuration process. Thin provisioning offers
this capability.
1.2 DS8000-specific implementations

The DS8000 provides two types of space-efficient volumes. Each type has a slightly different
implementation. This section gives a brief overview. The details for each type of
implementations are described in 3.2, Track space-efficient volumes on page 18 and 3.3,
ESE logical volumes on page 21.
1.2.1 Track space-efficient (TSE) volumes

Track space-efficient (TSE) volumes were introduced with the DS8000 Release 3.0 (License
Machine Code, LMC 5.3x.xx). TSE volumes were designed solely to support the IBM
space-efficient FlashCopy or FlashCopy SE feature. The allocation of real capacity for TSE
logical volumes is operated from a so-called repository volume, which has to be created per
extent pool. To create a repository volume, the amount of real capacity that it requires has to
be supplied. In addition, the repository also requires a virtual capacity to provide a pool for the
TSE logical volumes. The ratio of the virtual capacity to the real capacity represents the
storage over-commitment.
Because FlashCopy SE operates as a normal FlashCopy and the FlashCopy relations for
FlashCopy SE are no-copy relations, on-going writes to the primary volume will result in a
copy-on-write situation. Therefore, before a write to a track at the primary volume can take
place, the current content of the track has to be copied to the target volume. This happens on
a per track basis. TSE storage allocation has been implemented to allocate storage according
to the track-based copy process of the FlashCopy. The granularity of space allocation for the
TSE volumes is exactly one track, which is 64 KB.
1.2.2 Extent space-efficient (ESE) volumes

The ESE volumes are thin-provisioned volumes designated for standard host access. The
virtual capacity pool for ESE volumes is created per extent pool. Until Release 7.2, support
for an ESE repository did not exist. Now with Release 7.2, there is an option to create an ESE
repository in the extent pool where the ESE logical volumes exist or are planned to be
created. The best approach is to create an ESE repository in each extent pool that will be
used for ESE logical volumes. If there is no repository, the real capacity pool for allocation is
simply the unused space in the extent pool. For details, see 3.3.2, Optional ESE repository
for ESE logical volumes on page 21.
The allocation of real capacity for ESE volumes happens with writes to an unallocated
address (as is the case with TSE volumes). However, before the write, a new extent will be
dynamically allocated and assigned to the volume.
After the extent has been allocated, the extent has to be formatted. The extent initialization is
done by the Quick Init process introduced with the DS8000 microcode Release 4.3. With
Quick Init, volume initialization is much faster and replaces the previous initialization process.
Quick Init is invoked within standard volume creation, volume expansion, and dynamic
allocation of extents in thin provisioning. It also enables concurrent copy services operations.
The granularity with the ESE volume is one extent, which means 1 GB. With this approach,
the DS8000 takes advantage of its standard entities. At allocation time, there might be a slight
impact on the write performance. The response time for the first write operation might go up,
but not significantly. After the extent has been allocated and formatted, the ESE volume
performs the same as standard logical volumes.
Chapter 1. Thin provisioning
1.3 Terminology
In this section, we introduce additional terms related to thin provisioning and used in the
remainder of this book:
Virtual capacity
Virtual capacity is the capacity that can be used to create space-efficient volumes. The
virtual capacity is usually related to a physical entity (for example, an extent pool). The
virtual capacity has user-specified capacity value, which represents the amount of all
expected capacity to be used by space-efficient volumes.
Over-provisioning
Over-provisioning is the ratio of the virtual capacity to the real physical capacity.
Space efficiency
Space efficiency (SE) can be seen as a synonym for thin provisioning. In the DS8000, two
categories of space-efficient volumes are implemented, which are used for different
purposes.
Track space-efficient (TSE) volumes
TSE volumes are meant for use with space-efficient FlashCopy. For details, see 3.2, Track
space-efficient volumes on page 18.
ESE volumes
ESE volumes are denoted as common thin provisioning volumes. The virtual space is
provided from the free space of the DS8000 extent pools or, when defined, from the ESE
repository. For details, see 3.3, ESE logical volumes on page 21.
Chapter 2.
Planning considerations and

guidelines
This chapter presents general guidelines and discusses important considerations for taking
advantage of the thin provisioning functionality. The information applies to the Thin
Provisioning feature that is available for the IBM DS8870 with Licensed Machine Code (LMC)
7.7.20.xx.xx.
Note: In this chapter, the term thin provisioning is used as it relates to the extent
space-efficient (ESE) implementation only. The track space-efficient (TSE) implementation
is only supported for use with space-efficient FlashCopy target volumes.
2.1 General considerations

We start with general considerations regarding the use of thin provisioning.
2.1.1 Thin provisioning benefits

Thin provisioning offers the following typical advantages:
Reduced storage management efforts:
Exploiting over-provisioning in file systems, databases, and logical volume managers
without the underlying physical capacity to be present.
Real capacity can be added transparently to the software stack later, as required.
Improved capacity utilization:
Physical capacity is not allocated until it is actually used.
Unused capacity for a set of volumes resides in a shared pool of overall available
capacity.
Contingency capacity can therefore be shared between this set of volumes. The
average contingency capacity per volume can be less - compared to the case where it
cannot be shared and every volume has contingency capacity allocated. This leads to
higher utilizations of the existing physical storage capacity; therefore, acquisitions of
additional physical capacity might be reduced or deferred to a later point in time.
By sharing the capacity in a pool used to provision a set of space-efficient logical
volumes, deviations in allocation requirements of specific volumes tend to average out
over the whole capacity pool. This increases the amount of tolerable over-commitment
overall and makes it more predictable.
The limit of tolerable over-provisioning without running into out-of-space conditions
depends on the following circumstances:
Characteristics of the applications using the space-efficient volumes

Granularity of incremental capacity allocations to the space-efficient volumes
Rates at which capacity is consumed versus being released
In general, there is a trade-off between performance and space-efficiency, which depends on

the granularity of capacity allocation:
A fine granularity leads to the best space efficiencies, but might introduce performance
problems, because of the overhead involved in the administration for accessing metadata,
capacity allocations, and updating metadata on a small scale. This might also introduce
issues with sequential performance, when the sequential ordering of the data written is not
maintained, and therefore not transformed into a sequential set of logical tracks within the
allocated capacity on the DS8000 logical volume.
A coarse granularity might be less space efficient for the applications but it tends to have
less impact on performance due to the following circumstances:
Larger capacity allocated at one time, therefore fewer allocations are necessary for a
certain amount of data.
Reduction in metadata accesses to determine whether capacity is allocated.
Fewer updates required to the metadata to reflect the changes in allocations.
More friendly for sequential workload, because sequential logical tracks are grouped
into fewer capacity allocations.
In the DS8000 thin provisioning implementation (ESE volumes) with its granularity of 1 GB
extents, the metadata space overhead is small. It is only 0.44%, which means that every
extent used for metadata can manage 227,555 usable extents.
Quick Init is a function that allows a fast extent initialization process. This quick initialization
helps alleviate any performance implication resulting from the overhead introduced by the
nature of thin provisioning. Quick Init is up to 2.6 times faster than the regular initialization
process and is invoked every time that a new extent is added to an ESE volume.
Quick Init is also designed to start Copy Services operations directly after invocation, so there
is no need to wait for the initialization process to finish.
2.1.2 Recommendations
This section discusses specific elements to consider when planning to use thin provisioning.
Virtual capacity
Virtual capacity needs to be sized and configured before ESE volumes can be created. As
explained in Chapter 5, DS GUI and DS CLI support for thin provisioning on page 41, the
SM GUI will automatically create a specified amount of virtual capacity. However, the DS CLI
requires the amount of virtual capacity to be explicitly created. There are extra considerations
with it:
The amount of virtual capacity defined versus the real capacity available determines the
over-provisioning ratio. Therefore, plan well ahead to make sure it is appropriate (and
monitored to stay appropriate over time), as described in Chapter 6, Managing and
monitoring thin-provisioned volumes on page 75.
Virtual capacity can be increased as needed as long as free extents remain available.
Virtual capacity can only be deleted when there are no ESE or TSE volumes in the extent
pool. This underscores the importance of adequate planning for when and how much
virtual capacity is needed.
Note: Virtual capacity is needed for both ESE and TSE volumes. It is handled through a
single parameter called -vircap. Although virtual capacity can be expanded as long as
there are free extents available in the extent pool, the repository capacity for TSE volumes
cannot be expanded. Virtual capacity cannot be reduced easily; it can only be deleted
when there are no ESE or TSE volumes configured in the extent pool.
Over-provisioning
Over-provisioning is the ratio of virtual capacity to real capacity. The virtual capacity is the
amount of storage that is committed to the applications. The real capacity is the installed
hardware capacity.
Over-provisioning is a key consideration in a thin provisioning environment. To size the real
capacity pool, which translates into real storage hardware investment, the sustainable
over-commitment or over-provisioning has to be determined. Over-provisioning allows you to
save or defer the cost of hardware investments, but also introduces the risk of running out of
real capacity in a running production.
Chapter 2. Planning considerations and guidelines
A generic recommendation about sustainable over-provisioning ratios is difficult to give,

because the workloads and client requirements vary broadly. A conservative approach when
starting with over-provisioning in an existing environment is to use ESE volumes exclusively,
assume a 1:1 over-commit ratio initially, and monitor what storage remains unallocated. This
way, the storage administrator gets a better understanding of which volumes tend to
under-provision their configured size, which allows a better estimation of how much
over-commitment is sustainable in this environment.
For any ESE volume that is overcommitted, the client must have an understanding of the
impact of running out of space in their environment and what actions will need to be taken to
recover from the situation. The DS8000 provides options to reserve a capacity buffer and to
set thresholds for monitoring purposes, as described in Chapter 6, Managing and monitoring
thin-provisioned volumes on page 75. Another better approach, available with DS8870 R7.2
and higher, is to create an ESE repository. See 3.3.2, Optional ESE repository for ESE
logical volumes on page 21.
The trade-off between cost savings and risk of outage is controlled by the over-provisioning
factor. This value must be obtained carefully. The following procedure is proposed to help you
determine an acceptable over-provisioning value:
1. Perform an analysis of the current storage utilization on a per server or application basis.
Use the ratio of the assigned capacity to the used capacity as a first general indication for
a possible over-provisioning value.
2. Create an estimate of future capacity needs to determine if the over-provisioning value
obtained in step 1 will remain constant over time. Perform a review of the storage
demands history across all applications that are candidates for thin provisioning. The
outcome of this review will be an indication of how to adjust the over-provisioning ratio.
For example, if you have in your environment many applications with low or moderate
storage growth and only a few applications with dynamic storage growth, you can adopt a
more aggressive over-provisioning value because the demands of the few dynamic
applications can be supplied by a huge base of applications with unused storage capacity.
Every application is driven by the business for which it was designed. In this sense, knowing
the expected development of the business behind that application will also give some
indication of the future storage demands. If a high growth of storage demand is expected, it
might be appropriate to reduce the over-provisioning ratio to lower the risk.
You can order a Capacity on Demand feature from IBM as an option to have additional
contingency capacity. This feature ensures that the physical hardware required for a capacity
upgrade is already installed. Therefore, it only has to be activated when needed.
Extent pools
In a mixed extent pool, that is, one with both standard volumes and ESE volumes, the
available free extents can be allocated to either type of volumes. But every new standard
volume created is reducing the number of free extents (unless an ESE repository was
defined), therefore increasing the over-provisioning ratio for the ESE volumes. That means,
from a management perspective, it is probably desirable to have standard volumes and ESE
volumes in separate extent pools. This does not apply as much to TSE volumes, because the
repository capacity is fixed and there can be only one repository in an extent pool.
Subsequent creations of TSE volumes therefore have less of an impact on standard volumes.
For the ESE volumes, the dependency is only the virtual capacity and its limits.
10
Note: Minimizing the number of extent pools is maximizing the options to share the
contingency capacity between the volumes inside the individual extent pools. This helps
avoid out-of-space conditions in one extent pool while other extent pools might still have
enough contingency/buffer capacity available.
Note: The DS8000 thin provisioning implementation offers the flexibility to have both
standard volumes and thin-provisioned volumes in the same extent pool, which provides a
choice, unlike other implementations. The recommendation to have separate extent pools
for the two volume types is based on an ease of management perspective.
RAID levels
From a thin provisioning perspective, RAID-5 provides the most balanced approach between
space efficiency, resiliency, and performance. RAID-10 provides increased performance but
does not fit well into a space-efficient concept because it requires much more real capacity.
RAID-6, however, provides an increased level of resiliency against disk drive failures but is
also less space efficient than RAID-5.
Out-of-space behavior
Over-provisioning or over-commitment of capacity can result in a situation where the needed
capacity exceeds the capacity that is still physically available. In the DS8000 implementation
of thin provisioning for any write operations exceeding this amount, a write inhibit is sent to
the host, which will typically cause the software to fail. The DS8000 rejects write accesses to
the affected volumes until the required additional real capacity is made available for
allocation.
It is important to determine the tolerable over-provisioning ratio for a specific environment as
a realistic, stable average over time and use the threshold mechanisms that are provided to
receive warnings ahead of time. For this purpose, the thresholds need to be set according to
the individual client needs driven by the workload and application characteristics.
The following options are available to release allocated extents

The current implementation of DS8000 thin provisioning does not provide a mechanism to
release space on less than an entire logical volume:
Deleting an ESE volume will release all its allocated extents (real and virtual capacity).
The real and virtual extents become available for reallocation.
Requesting volume initialization through DS CLI/GUI will release all its real extents.
A SCSI Format Unit command issued by the attached host will release its real extents.
Important: For critical applications, standard logical volumes might be a better choice to
avoid any risk of running into an out-of-space situation.
11
2.1.3 Sizing
The following size maximums apply to the DS8000 ESE thin provisioning implementation:
Up to 4 PB total capacity (real and virtual) per storage facility image

Up to 4 PB total capacity (real and virtual) per extent pool
Up to 2 PB virtual capacity per extent pool
Up to 2 TB logical unit numbers (LUNs) for open systems
Up to 65280 logical devices
2.1.4 Performance
You might think that thin-provisioned volumes have lower performance than standard volumes
because some overhead is always involved in managing thin-provisioned volumes.
Performance measurements show nearly no performance impact associated with the
DS8000 ESE implementation of thin provisioning. The determining factors for this result are
the granularity of the capacity allocation (1 extent = 1 GB) and the fast initialization process,
which is referred to as Quick Init, for newly allocated extents. From a performance
perspective, ESE volumes are therefore in general suited for production volumes.
2.1.5 Applications
The efficiency of thin provisioning is dependent on the behavior of the applications in general,
especially in the way that they allocate space for their data. You must carefully select the
applications that can actually benefit from it. The application that performs this function is
typically a file system, or a database in cases where a file system is not used.
Ideally, the space allocation of the applications needs to have the following characteristics to
benefit from thin provisioning:
The application tends to localize its data in contiguous regions, rather than scatter the data
across the assigned ESE volume.
The application tends to reuse previously used space before using new space that was
never used before (using new space might trigger the allocation of more real capacity
extents to the assigned ESE volume). When the file system or database deletes data, the
space consumed by this deleted data is not automatically released.
Ideally, you want the application storage needs to increase monotonically over time.
The capacity allocation granularity of a specific implementation (1 GB ESE, 64 KB TSE) might
not be appropriate for certain applications.
The application (file system or database) might manage data in such a way that it ends up
fully allocating the volume even when the stored data at any certain time is actually much less
than the full volume capacity.
In general, the use of a Logical Volume Manager (LVM) is not expected 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 aligned with an extent boundary of the logical
volume to improve the likelihood that the extent remains unallocated. This might not be easy
to determine in practice.
12
If a file system is used, this file system is expected to be the determining factor regarding the
interaction with thin provisioning. Databases typically can operate with or without a file
system. Without a file system, the database behavior is expected to be the determining factor
regarding the interaction with thin provisioning. For instance, if the database has the
characteristic of initializing all of its configured table spaces, any associated ESE or TSE
volumes will end up fully allocated, making thin provisioning useless in this case.
More information about platform and file system-specific behavior is in Chapter 7, Host
considerations and migration to ESE volumes on page 81, as well as considerations and
tools for migration to ESE volumes.
Note: It is beyond the scope of this paper to identify software or applications in relation to
their compatibility with the DS8000 Thin Provisioning feature.
2.2 Planning steps

To determine an appropriate DS8000 configuration with thin provisioning in a specific
environment, the following data is required. The data must be carefully gathered. The order is
not relevant at this point, but all steps and related information are required to specify what
DS8000 features to order:
1. Determine the needed capacity for standard volumes, and plan for growth.
2. Determine the desired capacity for ESE, and plan for growth.
3. Consider defining an ESE repository.
4. Determine a sustainable over-provisioning ratio for ESE based on applications, workloads,
buffers, monitoring, and a contingency plan.
5. Determine the desired capacity for TSE, and plan for growth.
6. Determine a sustainable over-provisioning ratio for TSE (typically higher ratio tolerable
than ESE).
7. Determine other factors for DS8000 configuration, and model the workload with Disk
Magic.
8. Calculate the required real capacities and model the required feature codes by using
Capacity Magic.
Based on results, determine the required DS8000 configuration and feature codes.
2.2.1 Planning examples

The following sections describe several planning illustrations for different thin provisioning
scenarios.
13
Examples including thin provisioning and FlashCopy SE

To determine an appropriate DS8000 configuration, we use the following steps:
1. Specify the required standard and virtual capacities.
2. Specify sustainable over-provisioning ratios for both TSE and ESE.
3. For all volume types, calculate the real capacity that is needed, including metadata
overhead.
4. The overall real capacity that is needed plus the performance requirements (results from
Disk Magic modeling) determine the correct feature codes to order.
Input parameters are needed as specified in steps 1 and 2. In step 3, the overall required real
capacity is calculated based on the over-provisioning ratios and needed metadata. In step 4,
the results from the Disk Magic modeling need to be included to determine which drive types,
sizes, and RPM speeds are required for the provided capacity to meet the performance
criteria and the capacity criteria.
In our illustrations, we cover steps 1 to 3 only. We also made the following assumptions:
Only RAID-5.
No Serial Advanced Technology Attachment (SATA) disks.
Usable disk capacity: 90%.
The number of frames needed will be listed for a single drive type configuration only. A mix
of drive types can lead to the need for more spare drives. A mix of drive types also
depends on the creation order of the different arrays.
After the required real capacity is calculated, you can use Capacity Magic to determine the
configurations and drive sets to order.
The calculations for our examples are summarized in Table 2-1. Two example configurations
for the required capacities have been calculated already. Two columns are left empty so that
you can start calculating your required capacity configuration along the same lines.
Table 2-1 Calculation of required capacities and number of drivesets needed by disk capacity
14
Example 1
Example 2
Input: Real
capacity for
standard volumes
(GiB)
8192
16384
Input: Virtual
ESE capacity
required (GiB)
8192
32768
Input:
Overcommit ratio
for ESE
6:5
6:5
Input: Virtual TSE

capacity required
(GiB)
512
2048
Input:
Overcommit ratio
for TSE
8:1
8:1
Example 1
Example 2
TSE Repository
real capacity
(GiB)
64,70
258,82
Metadata
overhead for TSE
extents (GiB)
2,25
9,01
Metadata
overhead for ESE
extents (GiB)
36,00
144,00
Total real
capacity needed
for ESE capacity
(GiB)
6862,67
27450,67
Total real
capacity needed
for TSE capacity
(GiB)
66,96
267,83
Total real
capacity needed
in DS8000 (GiB)
15121,62
44102,49
146 GB disks
(6+P: 788,4 GB)
(7+P: 919,8 GB)
-> base frame

with 8 arrays 6+P
and 8 arrays 7+P
(8 drivesets total)
and first
expansion
frame with 4
arrays 6+P (2
drivesets total)
-> base frame

with 8 arrays 6+P
and 8 arrays 7+P
(8 drivesets total)
and first
expansion
frame with 16
arrays 6+P and
16 arrays 7+P (16
drivesets total)
and second
expansion
frame with 4
arrays 6+P and 2
arrays 7+P (3
drivesets total)
300 GB disks
(6+P: 1620 GB)
(7+P: 1890 GB)
-> base frame

with 6 arrays 6+P
and 4 arrays 7+P
-> 5 drivesets
total
-> base frame

with 8 arrays 6+P
and 8 arrays 7+P
(8 drivesets total)
and first
expansion
frame with 4
arrays 6+P and 4
arrays 7+P (4
drivesets total)
-> number of
drivesets needed
for this real
capacity:
- 6+P arrays
- 7+P arrays
15
450 GB disks
(6+P: 2430 GB)
(7+P: 2835 GB)
Example 1
Example 2
-> base frame

with 4 arrays 6+P
and 4arrays 7+P
-> 4 drivesets
total
-> base frame

with 8 arrays 6+P
and 8 arrays 7+P
(8 drivesets total)
For Reference,
to determine the
number of frames
needed:
16
Base frame max

# drivesets:
Base + first
Expansion
maximum # drive
sets
24
Base + first,
second
Expansion
maximum # drive
sets
40
Base + first,
second, and third
Expansion
maximum # drive
sets
56
Base + first,
second, third,
and fourth
Expansion
maximum # drive
sets
64
Chapter 3.
Space-efficient volumes in the

DS8000
This chapter describes the design and implementation of space-efficient (SE) volumes in the
DS DS8000. As seen in the introduction chapter, there are two types of space-efficient
volumes in the DS8000:
Track space-efficient (TSE) volumes
Extent space-efficient (ESE) volumes
TSE logical volumes are designed for use as space-efficient FlashCopy targets and are
supported only in that usage. ESE logical volumes are meant to support thin provisioning in
general.
Applications and operating systems that are appropriate for thin provisioning can use ESE
logical volumes for their storage needs.
Although TSE logical volumes require that a TSE repository exists in the extent pool, the ESE
logical volumes have no such requirement. Until Release 7.2 (IBM DS8870 with Licensed
Machine Code (LMC) 7.7.20.xx.xx), support for an ESE repository did not exist. Now with
Release 7.2, there is an option to create an ESE repository in the extent pool where the ESE
logical volumes exist or are planned to be created. The preferred practice is to create an ESE
repository in each extent pool that will be used for ESE logical volumes.
17
3.1 DS8000 logical volumes

With the introduction of DS8000 Release 4.3 and thin provisioning, three types of volumes
are now available:
Standard logical volumes
Standard logical volumes are the regular type of volumes. These volumes are fully
provisioned with real capacity.
Track space-efficient logical volumes
Track space-efficient logical volumes are used as target volumes of a FlashCopy SE
operation (with a nocopy option). Because in a nocopy relation, only modified data is
copied to the target volumes, this kind of space-efficient volume can operate with a high
over-provisioning ratio.
Extent space-efficient volumes
Extent space-efficient volumes are implemented to allow thin provisioning in general and
are dynamically provisioned using the DS8000 regular extents. When an ESE logical
volume is initially created, the volume has no real data capacity. However, the DS8000 will
use some real capacity for metadata that it uses to manage space allocation. The
metadata holds information about extents and volume blocks already allocated in a rank.
This metadata that is used for thin provisioning allows the DS8000 to determine whether
new extents have to be allocated or not.
Quick initialization
Allocating usable space for a DS8000 (standard) volume takes place at the time the volume is
created. The volume creation is done from the DS CLI or the DS GUI. Subsequently, a
process starts in the background to format the whole volume. Although the formatting process
is on-going, the volume is immediately accessible for servers.
Quick Init shortens significantly the time required to format a volume. In addition, Quick Init
enables all copy services for standard logical volumes to be established immediately. The
Quick Init provides the capability to allocate individual extents dynamically, when required, by
a write operation to an ESE logical volume.
3.2 Track space-efficient volumes

A FlashCopy with the nocopy option is typically used with the goal of taking a backup from the
FlashCopy target volumes. Without the use of space-efficient volumes, target volumes
consume the same physical capacity as the source volumes. Moreover, these target volumes
are often nearly empty because space is only occupied on demand, when a write to the
source volume occurs. Only changed data is copied to the target volume. A space-efficient
volume only uses the space needed for updates to the source volume.
The DS8000 provides the function FlashCopy SE, where the target volume of a FlashCopy is
defined as a TSE logical volume. TSE logical volumes can only be created when the
FlashCopy SE licensed feature is installed on the DS8000. The logical volumes can be either
fixed block (FB) or count key data (CKD). TSE logical volumes appear to a server as standard
logical volumes.
18
3.2.1 Repository for track space-efficient logical volumes

The definition of TSE logical volumes begins at the extent pool level. TSE logical volumes are
defined from virtual space in that the size of the TSE logical volume does not initially use
physical storage. However, any data written to a TSE logical volume must have enough
physical storage to contain this write activity. The repository provides this physical storage.
The repository is an object within an extent pool with a physical size that cannot be greater
than the physical capacity of the extent pool in which it is created. It is the physical space that
is available for all TSE logical volume data, in the extent pool. The repository is striped across
all ranks within the extent pool. There can only be one TSE repository per extent pool.
There is metadata (overhead) space required for the TSE repository, which is based on the
size of the repository. The metadata space is approximately 1% of the repository size. For
example, if the TSE repository is 1000 GiB in size, the metadata space configured in the
extent pool to support the repository is 11 GiB.
Important: The size of the repository and the size of the virtual space are part of the
extent pool definition. Each extent pool can have a TSE logical volume repository, but this
physical space cannot be shared between extent pools.
Initially, the virtual capacity of an extent pool is 0 (zero), but it is automatically increased as
space-efficient volumes are created. After the repository exists, the virtual capacity can be
increased using the chsestg command. It is not possible to decrease the virtual capacity of an
extent pool.
The virtual size of an extent pool is the sum of virtual storage that is available for TSE and
ESE logical volumes. For example, there can be a repository of 100 GB physical storage, and
you define a virtual capacity of 200 GB. In this case, you can define 10 TSE LUNs with
20 GB each, which means the logical capacity can be larger than the physical capacity. Of
course, you cannot fill all the volumes with data because the total physical capacity is limited
to 100 GB in this example.
The virtual capacity of an extent pool is reset to 0 (zero) whenever the TSE repository is
deleted, if it increased from 0 (zero) as a result of allocating TSE logical volumes or using the
chsestg command to change its size, after the TSE repository was created.
Note: In the current implementation of TSE volumes, it is not possible to expand the size of
the repository. Therefore, you must plan carefully for the size of the repository before you
use it. If a repository needs to be expanded, you must delete all TSE logical volumes within
the extent pool. Then, delete and re-create the repository with a different size.
Space for a TSE logical volume is allocated when a write occurs. More precisely, it occurs
when a destage from the cache occurs. The allocation unit is a track, which is 64 KB for open
systems logical unit numbers (LUNs) or 57 KB for CKD volumes, which you must consider
when you plan for the size of the repository. The amount of space that gets physically
allocated might be larger than the amount of data that was written. If there are 100 random
writes of, for example, 8 KB (800 KB in total), we probably allocate 6.4 MB (100 x 64 KB). If
there are other writes changing data within these 6.4 MB, there will be no new allocations at
all.
Chapter 3. Space-efficient volumes in the DS8000
19
Because space is allocated in tracks, and the system needs to maintain tables where it places
the physical track and how to map it to the logical volume, there is some overhead involved
with space-efficient volumes. The smaller the allocation unit, the larger the tables and the
overhead. The DS8000 has a fixed allocation unit of a track, which is a good compromise
between processing overhead and allocation overhead.
Summary: Virtual space is created as part of the extent pool definition. This virtual space
is mapped onto the repository (physical space) as it is used. Virtual space equals the total
space of the intended FlashCopy source volumes or space to contain the size of TSE
logical volumes that are intended to be used for other purposes. No actual storage is
allocated until write activity occurs to the TSE logical volumes.
Figure 3-1 illustrates the concept of TSE logical volumes.
Virtual repository capacity
Allocated tracks
Used
tracks
Extent
Pool
Space
efficient
volume
Ranks
Repository for
space efficient
volumes
striped across
ranks
normal
Volume
Figure 3-1 Concept of TSE logical volumes
The green blocks represent the available extents in the extent pool. One thing that is not
shown in this figure is the extents used for metadata (overhead) to support the TSE logical
volume. The metadata must use extents in the pool, therefore reducing the number of
available extents in the pool. The number of metadata extents required is based on the size of
the virtual capacity of the extent pool. The metadata for the virtual capacity is approximately
.45% (point four five) of the virtual capacity set for the extent pool. For example, with the
virtual capacity of the extent pool set to 1000 GiB, the metadata will use 5 GiB space.
To complete the picture, with the 1000 (one thousand) GiB repository and the virtual capacity
of 10000 (ten thousand) GiB configured in an extent pool, the total metadata space that is
configured is 56 GiB. The total allocated space in the extent pool is 1056 GiB. If the virtual
space is used to create TSE logical volumes of 10000 GiB, the opratio (over provisioned
ratio) will be 10.
For more details about TSE logical Volume implementation in the DS8000 and FlashCopy SE
implementation, see IBM System Storage DS8000 Series: IBM FlashCopy SE, REDP-4368.
20
3.3 ESE logical volumes

ESE logical volumes are used for general thin provisioning with the DS8000. The allocation
management for ESE logical volumes is generally based on the DS8000 standard storage
entities. This means that the dynamic allocation increments for ESE logical volumes is based
on the same existing 1 GB extents used for standard volumes. Because there is no extra work
to access ESE logical volumes, write operations to ESE volumes are similar in performance
to write operations on standard volumes.
To create ESE logical volumes, the Thin Provisioning licensed feature must be installed on
the DS8000. This feature only supports FB type logical volumes.
3.3.1 Metadata
Similar to TSE logical volumes, an ESE logical volume uses virtual capacity in the extent pool
to support the volume being allocated. When it is initially created, the volume uses no
physical capacity. However, the DS8000 must have metadata space available to support the
allocation of the ESE logical volume. The metadata holds information about extents and
volume blocks already allocated in a rank. This metadata that is used for thin provisioning
allows the DS8000 to determine whether new extents have to be allocated as data is written
to the volume.
The metadata space is determined by the virtual capacity setting of the extent pool. When the
extent pool is created, the virtual capacity of the extent pool is 0 (zero). There is no metadata
space required at this point. As ESE logical volumes are created, the virtual capacity is
automatically increased to support the total size of the volumes. As the virtual capacity is
increased, metadata space is allocated to support the virtual capacity that is set. As with TSE
logical volumes, the metadata space required is .45% (point four five) of the virtual capacity.
Managing virtual capacity

The easiest way to manage the virtual capacity of the extent pool is to increase the virtual
capacity automatically. As new ESE logical volumes are created, the DS8000 will
automatically increase the virtual capacity of the extent pool to support the total capacity of
the ESE logical volumes. This is the only choice you have if there is no ESE repository in the
extent pool.
The second way to manage virtual capacity is by using the chsestg command, but this will
only work if there is an ESE (or a TSE) repository that is already created in the extent pool.
Although this command uses the -reptype parameter, which can be ESE or TSE (TSE is the
default value), it is really setting the total virtual capacity of the extent pool and not for a
specific type of space-efficient volume.
3.3.2 Optional ESE repository for ESE logical volumes

Before R7.2 in the DS8000, the creation of ESE logical volumes did not allow for the use of an
ESE repository. The ESE logical volumes were able to use all of the available space in the
pool for allocated extents. With the introduction of R7.2, there is now an option to create an
ESE repository for the ESE logical volumes. This repository can be created within an extent
pool, just like the TSE repository. An extent pool can contain a maximum of one TSE and one
ESE repository. If an extent pool is going to be used for ESE logical volumes, it is better that
the extent pool has no standard volumes and only the ESE repository for the ESE logical
volumes.
21
The size of the repository can be set up to the total available space in the extent pool, but it
will still be included in the available space when displaying the available space in the
extent pool. Although it is included in the available space, it cannot be used for anything but
storing data on ESE logical volumes.
Unlike a TSE repository that must be created before any TSE logical volumes can be created,
the ESE repository can be created before or after the ESE logical volumes are created. If
created after, any existing ESE logical volumes will be automatically added to the repository.
In this situation, the size of the repository must be large enough to contain all of the current
allocated extents being used by the ESE logical volumes.
Unlike the TSE repository, which cannot be changed in size or deleted unless all TSE logical
volumes are deleted, the size of the ESE repository can be changed dynamically, both to
increase or decrease its size, and deleted altogether.
Although it might seem simpler to create ESE logical volumes without a repository, there are
benefits to using a repository:
The available space to store data on the ESE volumes is protected in the pool, and it
cannot be used for standard volumes, TSE repository space, or metadata when creating
new ESE volumes.
The opratio (over provisioned ratio) is fixed. This is most important because if you add a
new standard volume to the extent pool, the opratio will not change.
If adding physical capacity to the extent pool, the percentage of the size of the repository
to the size of the extent pool is maintained. Therefore, when capacity is added to the
extent pool, the size of the ESE repository is automatically increased. In this scenario, the
opratio will decrease as a result.
Future functions might require the existence of a repository.
Note: The opratio for ESE storage is the ratio between the total virtual capacity of all ESE
logical volumes and the available physical extents in the pool to store the data for those
volumes. If you have 10 - 100 GB ESE logical volumes and the available physical extents
to store data on those volumes is 100 GB, the opratio is 10.0.
The opratio is only indicated when a repository exists in the extent pool.
ESE volumes without an ESE repository

When using ESE logical volumes without a repository, there is no reserved space for storing
data on those volumes. The amount of space available to write data on the ESE logical
volumes is the available space in the extent pool. If the available space is subsequently
reduced because new standard, TSE (and TSE repository), or ESE logical volumes are
created, the amount of space available to write data on the current ESE logical volumes is
also reduced because no reserved space exists for the ESE logical volumes.
When an extent pool is created, the virtual capacity of the pool is 0 (zero). When an ESE
logical volume is created, the virtual capacity is automatically increased to support the size of
the ESE volume. There is a limit to the virtual capacity of an extent pool. This limit is based on
using all of the available space in the extent pool for metadata for space-efficient volumes.
Because ESE logical volumes do not require a repository, all of the extent pool can be used
for metadata, but that means that no space exists for writing data to the ESE logical volumes.
22
Therefore, it is important to plan the space for the ESE logical volumes, so that adequate
space exists in the extent pool to store all the planned data that might be written to volumes
and to accommodate the virtual capacity of the volumes. The difference between the virtual
capacity of the volumes and the space on which to store data on the volumes is the opratio.
There are various ways to determine the highest possible virtual capacity. One way is to take
the available space in the extent pool (assuming there is nothing configured in the extent
pool) and multiply that number by 200. Another way is to use the indication that is provided on
the GUI. Using the GUI, when creating new volumes with SAM type of ESE selected, at the
top of the Add Volumes panel, the current virtual capacity is displayed as the available
capacity. This value is based on the current available extents in the pool that can be used for
metadata. As you add more volumes, the required space for metadata will reduce the
physical space for writing data to the actual volumes, which will increase the opratio. If you
actually created ESE volumes using all of the indicated capacity, there will be no space to
store any data on those volumes, which will make them useless.
So, to plan out the ESE logical volumes, three choices are possible:
The first method is to take an extent pool that already exists. The first step requires that
you determine the physical space (or available space) in the extent pool. From that
number, subtract the amount of space you require to store data on all the ESE volumes
that you plan to create in the extent pool. The remaining capacity will be available for ESE
volume metadata. Multiply that number by 200 to calculate an approximate virtual capacity
for the extent pool that can be used to create ESE logical volumes. The problem that will
occur is that the opratio will probably be extremely high, and not at all practical. See
Example 3-1 to review this calculation using actual numbers.
Example 3-1 Existing pool
Available capacity (GUI) .... 481,694 GiB

Total extent pool capacity .... 2,122 GiB - actual physical capacity
Space for ESE volume data ..... 1,000 GiB - your decision
Allocated extent pool space ....... 0 GiB - assumes there is no TSE repository
or standard volumes
Space available for metadata .. 1,122 GiB
Approximate total virtual capacity for ESE volumes is 224,400 GiB
This would result in an opratio of 224:1 - an extremely high value
A second method is to determine the opratio that you want, with as low a number as
possible to start. Remember that you might be able to increase this number if usage
allows it, as monitored over time. Multiply the opratio by the space you want to be used to
store data for the ESE volumes that are created. The result will be your total virtual
capacity in the extent pool to create ESE volumes. See Example 3-2 on page 24 to review
this calculation using actual numbers.
23
Example 3-2 Using opratio
Available capacity (GUI) .... 481,694 GiB

Total extent pool capacity .... 2,122 GiB - actual physical capacity
Space for ESE volume data ..... 2,080 GiB - your decision
Allocated extent pool space ....... 0 GiB - assumes there is no TSE repository
or standard volumes
Space used for metadata .......... 42 GiB
Opratio ........................... 4:1
Approximate total virtual capacity for ESE volumes is 8,320 GiB
A third and more practical approach is to determine your ESE volume capacity
requirements, divide that number by your opratio requirement, and add space for
metadata (ESE volume capacity multiplied by .5). This will provide you with the required
storage capacity when you set up the extent pool. See Example 3-3 to review this
calculation using actual numbers.
Example 3-3 ESE capacity requirements
Total ESE volume capacity .... 10,000 GiB

Space for ESE volume data ..... 2,500 GiB
Space required for metadata ...... 50 GiB
Opratio required 4:1
Total extent pool capacity .... 2,550 GiB

Tools are available to assist you in planning your overall storage requirements in a DS8000.
They are explained in Chapter 2, Planning considerations and guidelines on page 7.
The DS8000 will create the virtual capacity needed for ESE logical volumes as they are
created. If you want, you can set the virtual capacity for the extent pool, or let it grow as
volumes are created. The total virtual capacity represents the sum of virtual storage that is
available for ESE logical volumes. Figure 4-2 illustrates the general concept of ESE logical
volume allocation without a repository.
Note: If the total virtual capacity is used and a new ESE logical volume must be created,
the virtual capacity of the pool can be expanded dynamically. This will happen
automatically when new ESE volumes are created. The creation of the new volume will
only be successful if there are sufficient available extents in the extent pool for the
metadata required for the new volume.
It is not possible to reduce the size of the pools virtual capacity.
24
Figure 3-2 Concept of ESE logical volume without a repository
Without an ESE repository, the real capacity is allocated using free extents from the extent
pool. Extents for standard logical volumes (if they exist) and dynamically allocated extents for
ESE logical volumes are allocated independently from the same extent pool. When the extent
pool has more than one rank, the dynamic allocation of extents follows the usual extent
allocation methods. That is, either rotate extents or rotate volumes, depending on what was
specified when the ESE logical volume was created.
Note: ESE logical volumes, TSE logical volumes, and standard volumes can coexist in the
same extent pool, although it is best to have only one type of volume per pool.
ESE volumes with an ESE repository

The repository for ESE volumes can be created before any ESE volumes are created, or after
the volumes are created. Like the TSE repository, only one ESE repository can be in an extent
pool. An extent pool can include both an ESE and a TSE repository but there can only be one
of each type.
A lot of flexibility is available when you work with the ESE repositories. ESE repositories differ
from the TSE type in the following ways:
The actual size allocated will be rounded up to the next highest whole number percentage
of the current physical extent pool capacity, not what is specified.
You can dynamically increase or decrease the size of the repository. If storage is allocated
in the repository, the size cannot be lower than the current allocation.
You can specify a size starting at 0 GB.
If created after the ESE volumes exist, those volumes and any additional volumes will use
the repository space for storing data on the volumes.
25
The ESE repository can be deleted without deleting any volumes, even if data is allocated.
The ESE repository automatically changes size when changing the physical capacity of
the extent pool, to maintain the size percentage of the repository to when it was created.
No overhead is required for the repository.
There are also certain restrictions in working with ESE repositories:
The ESE repository is only supported with FB type storage.
It can only be created, managed, and deleted by DSCLI commands.
The DS GUI does not provide any details for the ESE repository.
When using DSCLI commands, if -reptype is an optional parameter, the default value is
TSE. For example, when you use the showsestg command, be sure to use the parameter
-reptype ESE for the ESE repository details. If you do not specify the repository type, you
see the TSE repository details if the TSE repository exists, or it will respond with
Space-Efficient Storage pxx does not exist.
When you choose the capacity of the ESE repository, it is important to remember that it can
be dynamically changed to meet future needs, as required. If it is created before the ESE
volumes are created, also remember that space must be available in the extent pool for the
metadata of the volumes that you plan to create.
When you work with extent pools, an available space is indicated based on the current
configuration. Unfortunately, when you create an ESE repository, the space designated for
the repository remains in the available space for the extent pool, because the repository can
be removed at any time. Only as space in the repository is used to store volume data is the
available space reduced by the amount of the repository space that is used. Remaining
space in the repository is still considered available in the extent pool. Although it is indicated
as available space in the repository, in reality, the space cannot be used for anything else
but storing data for ESE logical volumes. Any attempt to use this reserved available space
for configuring volumes or a TSE repository will fail.
Because there is reserved capacity for storing data on the ESE volumes, the remaining
free or available extents in the extent pool can be used to increase the size of the repository,
or increase the virtual capacity of an existing ESE volume or create a new ESE volume. As
well (although not advised), it can be used to create standard volumes, or a TSE repository
and volumes.
To calculate the real available capacity, after the ESE repository is created, you must perform
these tasks:
1. Determine the available capacity (use the lsextpool command).
2. Subtract the ESE repository capacity (use the lssestg command).
3. Add the ESE repository allocated capacity (use the lssestg -l command).
Trying to determine the amount of virtual space that is available to use can be a challenge.
You can use the same means as described earlier to determine the space with which to work,
but change the space for ESE volume data to ESE repository size. The purpose of the
repository is to provide space for the ESE volume data. This will give you the details
concerning capacity when you use an ESE repository.
26
Figure 3-3 illustrates the general ESE logical volume when using an ESE repository.
Figure 3-3 Concept of ESE logical volume with a repository
With the repository in the extent pool, any extents required for storing ESE volume data will
be allocated from the extents that belong to the repository (just like TSE volumes), and not
from the free extents in the extent pool.
3.3.3 Capacity allocation for ESE volumes

When a host writes data to an extent of an ESE logical volume and the extent does not have
an associated real extent, the write operation is held in abeyance until a real extent from the
extent pool is dynamically allocated to the ESE logical volume. If there is a repository, an
available extent that belongs to the repository will be allocated. If there is no repository, an
available extent in the extent pool will be allocated. This process is applied primarily in the
cache of the DS8000 storage facility image. Now, the write data is accepted into the write
cache. Whenever a real extent is allocated to an ESE volume, the Quick Init process is
invoked to dynamically initialize the tracks on the real extent that have not been written by the
requesting write operation. This quick initialization is performed in parallel with the host
access. When the quick initialization has finished, the extent is ready for normal operations.
Any subsequent write operations that might cause one or more destages of tracks can also
now be applied to the new extent.
27
Depending on the incoming I/O operation and the current status of the volume, different
situations can occur and are handled as described:
Write access to a DS8000 block within the allocated capacity
The block is already allocated in an extent. The write operation continues normally, where
data is stored in the write cache and the write is committed to the application server. Upon
a destage from cache to disk, data is written to the appropriate block in the extent that was
allocated.
Write access to a DS8000 block where no capacity is allocated
The DS8000 dynamically allocates to the logical volume the capacity needed to store the
write data to disk. For an ESE logical volume, the capacity allocated is one extent. The
data is stored into the write cache and the write is committed to the application server. At
this time, unused data in the extent is initialized (with Quick Init). Upon a destage from
cache to disk, data is written to the appropriate block in the extent that was allocated.
Read access to a DS8000 block with allocated capacity
This is the same situation as in a standard logical volume. When the data is not already in
the read cache, a stage operation will direct the read operation to the logical block and
load the data into the read cache for the next potential reads.
Read access to a DS8000 block where no capacity is allocated
The data for this logical block is synthesized in the read cache with an initialization pattern.
Read operations to unallocated capacity will normally not happen from an application
standpoint, because applications typically read data already stored on disk. In other
words, it is unlikely that data is used, when it has never been written. From the standpoint
of the operating systems and lower levels, reads from un-allocated capacity can happen
because all blocks of volume include the virtual capacity can be addressed by the host.
The extent pool is equipped with parameters to allow monitoring of the real capacity
utilization. The most important parameters are listed. These parameters are available for real
and for virtual capacity. The values can be obtained for each extent pool with the DSCLI
command showextpool:
configured
Gives the number of real extents that are configured to the extent pool.
allowed
The number of real extents that remain, when a limit has been set. If the limit is disabled or
has been set to 100%, the allowed extent has the same number as the configured extent.
available
The number of extents that are free to be allocated either by standard logical volumes or
ESE logical volumes. If an ESE repository exists, available repository extents are included
in this number.
allocated
The value of allocated real extents. It is the sum of extents allocated in standard logical
volumes and ESE logical volumes.
3.3.4 Out-of-space condition

When a write operation requires another extent allocation, but all real extents are already
used up, the write operation is rejected by the DS8000.
28
If there is no ESE repository, this out-of-space condition will remain until new physical
capacity is made available to the DS8000 storage facility image. Therefore, one or more
additional ranks must be assigned to the specific extent pool. If ranks are available in the
DS8000 frames, but have not been configured yet, they can be configured now to the extent
pool. If ranks have been configured to the extent pool as reserved ranks, additional capacity is
made available by simply unreserving one or more of those ranks. Otherwise, one or more
new ranks have to be physically installed and subsequently added to the extent pool.
If there is an ESE repository, you can handle the situation in one of several ways. If there are
free extents in the extent pool, increase the size of the repository to use up to all of the free
extents. This will alleviate the problem, but it might only be temporary, depending on future
allocation requirements and how much additional space was added to the repository. If there
are no free extents in the extent pool, additional physical capacity will need to be added to the
extent pool. As soon as the additional physical capacity is added, the repository will
automatically increase in size, which will alleviate the out-of-space condition.
Important: Out-of-space conditions in an extent pool need to be avoided in any case,
because this definitely translates into application access loss.
An extent pool is characterized by parameters and functionality to allow monitoring of its
capacity.
One parameter is the extent threshold for the extent pool. This is important when operating
without an ESE repository. The threshold is set as a percentage of the number of remaining
available extents. For example, if the threshold is set to 15%, which is the default, a Simple
Network Management Protocol (SNMP) trap is sent out to the data center management
console as a warning that the remaining available capacity for this extent pool has fallen
below 15% of the overall initial capacity. However, real capacity (extents) can still be
allocated.
For additional safety, an extent limit can be configured. This limit provides a restricted amount
of capacity that is not initially accounted for as free extents in the extent pool. This gives you
an additional reserve that can be brought into the extent pool if you cannot install additional
capacity quickly enough after getting the first warning (from the extent threshold) that the
available capacity is already running low.
29
Figure 3-4 illustrates these concepts of threshold and extent limit without an ESE repository.
Virtual Capacity
Restricted Extents
Extent Limit
Extent Threshold
ESE LV
Free Extents
Used Extents for

ESE LV
Used Extents for

Standard LV
Standard
LV
Available Extents
Extent Pool
Figure 3-4 Extent pool space without an ESE repository
When you use an ESE repository, you can use repository parameters to monitor the
allocation of extents in the repository. One parameter is the repcapthreshold, which is used
to set the minimum percentage of available space in the repository. If the percentage of
available space falls below this parameter, the repository will be in a status of threshold
exceeded. This parameter is one of three threshold settings that exist for a repository. This
one is referred to as the user threshold. The other two thresholds are system controlled and
cannot be changed. They are 0% (repository full) and 15% (85% full). (See the mksestg
command in the DSCLI commands documentation for a complete explanation of this
parameter.) After a threshold is met, a notification will be sent out (if configured using the chsp
command).
In Figure 4-5, the layout of the extent pool is shown when using an ESE repository.
30
Figure 3-5 Extent pool space with an ESE repository
3.3.5 Volume creation

ESE logical volumes are created using virtual extents. The number of virtual extents that can
be created in the pool is based on the virtual capacity of the pool. The ESE logical volume will
initially have some real capacity allocated. This is necessary to store the volumes internal
metadata and is referred to as overhead. The metadata consists of a structure and data
about the extent, such as status information, address information, and other information used
by the DS8000 microcode. The capacity required by metadata is low (below 0.5% of the
logical volume capacity), but it uses real storage nevertheless. The overhead per extent pool
can be shown with the DSCLI command showsestg.
The more volume capacity that is created in the pool, the more metadata space is required.
This, in turn, will reduce the amount of space to store data on the volumes. Without a
repository setup for the ESE logical volumes, the available space to store data on the ESE
volumes will decrease as you add more volumes, whether they are ESE or standard, or if you
add a TSE repository for TSE volumes.
When an ESE logical volume is made accessible to the host, certain allocation operations
might be executed at the host to make the volume usable by the operating system and the
applications. Depending on the host platform, the allocation tasks will differ. For example, on
an IBM AIX host, the volume will be allocated to the volume manager by creating a volume
group first. During this process the Volume Group Descriptor Area (VGDA) and Volume Group
Status Area (VGSA) will be written to the volume, which will cause the dynamic allocation of
an extent. Allocation of the logical volume on the AIX host will also cause some writes to the
volume. The Enhanced Journaled File System (JFS2) then causes another write operation.
All of these steps taking place at the AIX host with JFS2 result in two extents being allocated
at the DS8000 back end. For more information, see Chapter 7, Host considerations and
migration to ESE volumes on page 81.
31
OS platforms or applications that cause the storage subsystem to claim the whole volume
capacity when attaching the DS800 logical volume cannot benefit from thin provisioning.
Such operating systems or applications need to use standard logical volumes.
3.3.6 Releasing space

After a file system or an application has allocated its initial storage and has been turned over
to production, new data will eventually be added, resulting in new storage allocation. Data will
also be modified or deleted. These operations will produce portions of unused space on the
volume from the host point of view, but also on the logical volumes of the storage subsystem.
This is generally known as fragmentation and occurs on space-efficient logical volumes and
on standard logical volumes in the same way.
For standard logical volumes, this situation is almost insignificant, because the whole capacity
(used or unused by the application) is exclusively assigned to the logical volume anyway. It is
more important to ESE logical volumes, because unused capacity resulting from data
deletions cannot be reused for the thin provisioning until it is released back to the real
capacity pool.
Currently, the only method to release space back to the real capacity pool is to remove the
ESE logical volume, or to issue an initfbvol command, which will initialize the whole
volume. To release space with this condition, a migration procedure to a new ESE logical
volume is enforced. Depending on the operating system or the application, this migration
might require downtime.
3.3.7 Migration considerations

Considerations are described about how to bring thin provisioning into production. It is
assumed that the applications and the operating system on which the applications are
running are viable candidates for thin provisioning.
Applications that currently use standard logical volumes need to be carefully analyzed to
determine how much storage capacity is not used from the server perspective. ESE logical
volumes are then assigned to the server and data can be migrated from the original standard
volumes to ESE volumes. At the end of the migration, the real capacity allocated to the ESE
logical volume needs to be typically equal to the capacity that was effectively used on the
standard logical volume. Depending on the application and operating system, it is possible
that a bit more capacity might be allocated. This might happen due to the additional metadata
required for thin provisioning and the behavior of the file system.
The actual data needs to be migrated using the host-based application methods or a Logical
Volume Manager (LVM)-based mirroring. Other methods that are provided by lower levels of
the operating system might not produce the intended result. For example, using the UNIX dd
command copies each block of the source device to the target device, which as a result
allocates all the capacity on the ESE logical volume.
3.3.8 Performance considerations

In general, a trade-off exists between space-efficiency and performance that depends on the
granularity of capacity allocation. A small granularity capacity allocation leads to the best
space efficiencies. However, it might have performance problems because of the overhead
involved with capacity allocation and the overhead involved with accessing metadata that
determines whether the capacity is allocated.
32
In the DS8000, allocation of space to an extent-space-efficient logical volume has the same
granularity (1 GB extent) as a standard volume. Therefore, the performance of I/O operations
on such an extent needs to be nearly identical to that of a standard logical volume.
Additionally, the overhead involved with the management of the ESE logical volume is
generally limited to the overhead involved with real extent allocation. Because there are a
large number of tracks per extent, the number of extent allocations that might occur is
relatively limited.
Issues can also exist with sequential performance 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 capacity allocation might be less space efficient for some applications, but it tends to
have fewer performance problems due to the reduction in the number of necessary capacity
allocations, the reduction in metadata required to determine whether capacity is allocated,
and the grouping of sequential logical tracks into capacity allocations.
A storage provisioning method used for a logical volume and its resulting performance and
storage allocation requirements might determine what applications are appropriate on a
certain logical volume. In general, use of a space-efficient logical volume must have some
mechanism to determine when to release physical space associated with the logical volume.
Or, the application must be well behaved so that it tends to limit where it stores the data that
exists on the volume to prevent allocation of more capacity than the data on the volume
requires.
33
34
Chapter 4.
Enabling thin provisioning

Thin Provisioning is a licensed feature of the IBM System Storage DS8000.
This chapter covers the following topics:
Licensing
Activation
Enabling
Disabling
This chapter also describes the effects of enabling and disabling thin provisioning on existing
volumes and existing space-efficient FlashCopy targets.
Note: The Thin Provisioning feature license applies only to extent space-efficient (ESE)
volumes.
35
4.1 Licensing
Thin Provisioning is an optional chargeable licensed function that must be enabled to be
used. Thin Provisioning is not a capacity-tiered feature. It can be enabled or disabled
regardless of capacity.
Thin Provisioning function is enabled through a 242x licensed function indicator
feature (0707), plus a licensed function authorization feature number (7071). The licensed
function indicator feature numbers enable the technical activation of the function, subject to
the client applying a feature activation code made available from IBM. The licensed function
authorization feature numbers establish the extent of authorization for that function on the
242x machine for which it was acquired.
4.2 Activation
You can activate the Thin Provisioning license key after the IBM service support
representative (SSR) completes the storage complex installation or upgrades the system with
the required DS8000 Licensed Machine Code (LMC). The activation code must be retrieved
from the IBM Disk Storage Feature Activation (DSFA) website:
http://www.ibm.com/storage/dsfa
Before you connect to the IBM DSFA website to obtain your Thin Provisioning feature
activation code, ensure that you have the necessary information about your storage system.
You can collect that information from the Storage Unit General Properties page in the IBM
DS8000 Storage Manager.
You will also need the following items:
The IBM License Function Authorization documents. If you are activating code for a new
storage unit, these documents are included in the shipment of the storage unit. If you are
activating code for an existing storage unit, IBM sends these documents to you in an
envelope.
USB memory device for downloading your activation code into a file if you cannot access
the DS Storage Manager from the system that you are using to access the DSFA website.
Instead of downloading the activation code in softcopy format, you can also print the
activation code and manually enter it using the DS Storage Manager GUI or DS CLI.
After you obtain the Thin Provisioning activation code, apply it to your DS8000 storage
images by using the DS Storage Manager GUI or DS CLI. When applied, the code enables
you to use the Thin Provisioning feature and to begin configuring virtual storage on a storage
image.
The activation of licensed functions is described in detail in IBM DS8870: Architecture and
Implementation, SG24-8085.
Figure 4-1 on page 37 shows Thin Provisioning activation codes as displayed by the DS
Storage Manager GUI.
36
Figure 4-1 DS Storage Manager GUI - Activation keys information
Example 4-1 shows Thin Provisioning activation codes listed by the DS CLI.
Example 4-1 DS CLI: Activation keys information
dscli> lskey IBM.2107-7520781

Date/Time: 2009. kolovoz 04 18:46:16 CEST IBM DSCLI Version: 5.4.30.210 DS:
IBM.2107-7520781
Activation Key
Authorization Level (TB) Scope
==========================================================================
High Performance FICON for System z (zHPF) on
CKD
IBM FlashCopy SE
276
All
IBM HyperPAV
on
CKD
IBM System Storage DS8000 Thin Provisioning on
All
IBM database protection
on
FB
Metro/Global mirror (MGM)
106,7
All
Operating environment (OEL)
105,6
All
Parallel access volumes (PAV)
105,6
CKD
Point in time copy (PTC)
105,6
All
Remote mirror and copy (RMC)
105,6
All
Remote mirror for z/OS (RMZ)
105,6
CKD
dscli>
Restriction: Thin Provisioning is activated for ALL (fixed block (FB) and count key data
(CKD) volumes) although it is not supported with CKD.
Chapter 4. Enabling thin provisioning
37
4.3 Enabling
When the Thin Provisioning license is activated on your DS8000, you can start creating
space-efficient volumes in an existing or a new extent pool and, therefore, start using the Thin
Provisioning function. You can now create volumes using the ESE storage allocation method.
Note: When you enable the Thin Provisioning function, the extent threshold for the existing
extent pools will change from 0% to 15%. Example 4-2 shows the new threshold value
after enabling thin provisioning.
Example 4-2 New threshold value after enabling thin provisioning
dscli> showextpool P10

Date/Time: 2009. august 04 21:16:40 CEST IBM DSCLI Version: 5.4.30.210 DS:
IBM.2107-7520781
Name
gero_0
ID
P10
stgtype
fb
totlstor (2^30B)
452
availstor (2^30B)
0
resvdstor (2^30B)
0
rankgrp
0
numranks
1
numvols
1
status
full
%allocated
100
%available
0
configured
452
allowed
452
available
0
allocated
452
reserved
0
%limit
100
%threshold
15
virextstatus
full
%virallocated
0
%viravailable
0
virconfigured
0
virallowed
0
viravailable
0
virallocated
0
virreserved
0
%virextlimit
%virextthreshold
encryptgrp
%allocated(ese)
0
%allocated(rep)
0
%allocated(std)
100
%allocated(over)
0
%virallocated(ese) %virallocated(tse) %virallocated(init) dscli>
38
Effect on existing FlashCopy TSE target volumes

To configure ESE logical volumes, there must be sufficient available virtual extents in the
extent pool to support the logical volumes. If track space-efficient (TSE) logical volumes are
already created in the same extent pool (and therefore already using virtual extents), you
must be aware of the total virtual capacity used by TSE and ESE.
Virtual capacity can be configured and expanded in an extent pool through DS CLI or it can
be done automatically by using the DS GUI to create TSE or ESE volumes. Virtual capacity
can be expanded as required up to the supported limits as described in Chapter 2, Planning
considerations and guidelines on page 7. Virtual capacity can be deleted from an extent pool
if there are no TSE or ESE logical volumes configured in the extent pool.
4.4 Disabling
To disable Thin Provisioning on a DS8000 where it was previously enabled and used, you
must first unconfigure all ESE volumes that are configured. Then, you can apply the
deactivation key. You need to obtain a new key from the IBM Disk Storage Feature Activation
(DSFA) website to disable thin provisioning.
You must apply the key on your DS8000 storage images by using the DS Storage Manager
GUI or DS CLI. When applied, the Thin Provisioning feature is disabled.
Deactivation of licensed functions is described in detail in IBM DS8870: Architecture and
Implementation, SG24-8085.
Chapter 4. Enabling thin provisioning
39
40
Chapter 5.
DS GUI and DS CLI support for

thin provisioning
This chapter explains the use of the DS GUI and DS CLI commands in support of thin
provisioning-related functions.
41
5.1 DS GUI and DS CLI support for thin provisioning

The creation of volumes in the DS8000 requires the specification of the Storage Allocation
Method or SAM attribute. This attribute determines the type of the logical volume that will be
created. You can create the following types of logical volumes:
Standard logical volume
Track space-efficient logical volume (TSE)
Extent space-efficient logical volume (ESE)
This chapter explains the various ways that ESE logical volumes can be implemented in the
DS8000. If you are familiar with TSE logical volumes, you know that they require the creation
of a repository before the volumes can be created in the extent pool. With ESE logical
volumes, you have a choice of whether you want to use an ESE repository for your ESE
logical volumes. This chapter provides details for both scenarios.
Thin provisioning allows you to create ESE logical volumes by specifying the ESE SAM
during volume creation. Virtual capacity must exist in the extent pool to configure an ESE
logical volume. The virtual capacity is automatically configured in the extent pool when you
create ESE logical volumes but it is limited by the available capacity of the extent pool. The
DS8000 maximum supported limit is 2 PB per extent pool.
Thin provisioning is only supported for fixed block (FB) volumes, and is not supported for IBM
System z CKD logical volumes.
In the next two sections, the procedures to create and manage ESE volumes are explained.
The first section covers the use of the DS GUI and the second section covers the use of the
DS CLI commands.
5.2 DS Storage Manager GUI

When using the thin provisioning feature to create and manage ESE logical volumes, it is
possible to use the DS GUI for certain functions. Although the GUI allows for the creation of
ESE logical volumes, it does not allow for the creation of the ESE repository. You can create
an ESE repository only by using a DS CLI command.
Because it is possible to use the DS GUI to create ESE logical volumes, we look at the
windows in the DS GUI that reference thin-provisioned storage in the DS8000, and then
discuss the process for creating the volumes. The details for the DS GUI that are explained
here assume that the icon navigation option is used.
The following GUI windows are used to create and manage ESE volumes:
42
FB Volumes main window

Add Volumes window
Internal Storage window and Extent Pools tab
Add Space-Efficient Repository window (storage in extent pools)
Extent pool properties window
FB Volumes main window

The FB Volumes window displays open systems storage information. You can use this
window to initiate actions that relate to open systems volumes. The top pane provides
summary information about the amount of standard capacity used by standard FB volumes
and the amount of virtual capacity used by the TSE and ESE volumes.
The capacities for each type are placed in four categories:
Host Assigned
Includes allocated capacity only for those volumes (standard, TSE, or ESE) in volume
groups that are assigned to a host connection
Unassigned in volume group (VG)
Includes allocated capacity only for those volumes (standard, TSE, or ESE) in volume
groups that are not assigned to a host connection
Ungrouped
Includes allocated capacity only for those volumes (standard, TSE, or ESE) that are not in
volume groups
Unallocated
The amount of standard and virtual capacity that is not allocated to volumes
Figure 5-1 shows the top pane of the FB Volumes window with the summary displayed as a
bar chart that includes TSE and ESE volumes. The quantities of each type by category are
shown on the right. Under each of the categories, the capacity of a volume type is only
included if it exists in the storage system.
Figure 5-1 Open systems volumes main page - ESE volumes in chart data
Chapter 5. DS GUI and DS CLI support for thin provisioning
43
Add Volumes window

The Add Volumes window is used to define the properties for the volumes being created. The
properties include selecting the storage allocation method. The thin provisioning feature
allows you to create an ESE logical volume by specifying the ESE storage allocation method
(SAM) during volume creation. This is depicted in Figure 5-2.
Figure 5-2 Storage allocation method: ESE
When you create ESE volumes, the amount of available capacity and projected remaining
capacity (as shown at the top in Figure 5-2) is the supported virtual capacity in the extent
pool. This capacity is based on the available extents in the extent pool that can be used for
the metadata (overhead) required for ESE volumes that can be created.
The amount of projected remaining capacity is calculated according to the values entered for
the size and volume quantity of ESE volumes in the window.
Important: If you accidentally specify all remaining capacity for the size of your ESE
volumes and they are created, your extent pool will be full. All available storage (real
extents) will be used for space-efficient metadata. Then, no extents are available to store
data in those volumes.

The Internal Storage window has three sections: Summary in the top section, Alerts in the
middle section, and Manage Internal Storage in the bottom section. The Summary section
provides information about the amount of total used real capacity for open systems and
System z. It includes a comparison of assigned real capacity and available real capacity. The
real capacity provides information for TSE and ESE volumes. There is no detail provided on
virtualized capacity.
Figure 5-3 on page 45 shows an example with configured ESE volumes. This display will be
the same regardless of whether ESE repositories are used.
44
Figure 5-3 Extent pools main page - ESE storage capacity
The Summary display shows a total of 5 GiB allocated for the TSE and ESE repositories in all
extent pools. Currently, both of these indications might not reflect the actual setup in the
DS8000. The next two paragraphs explain what each value indicates.
The Allocated to TSE repository value includes the total for all the TSE repository space,
plus the overhead for all TSE repositories, plus the overhead for all TSE virtual capacity setup
in the extent pools. Also, it can include the overhead required for ESE virtual space in all
extent pools. When the first ESE logical volumes are created in an extent pool, the virtual
capacity of the extent pool is automatically increased in the extent pool to support the ESE
volumes. This virtual capacity requires overhead to support the volumes that use the space.
Three situations will affect the total shown in this line:
If no TSE repository exists in the extent pool, this overhead capacity is assigned to the
Allocated to ESE repository line total as expected.
If a TSE repository already exists in the extent pool where the ESE volumes are created
(which increases the total virtual capacity in the extent pool), the virtual space overhead is
added to the Allocated to TSE repository total.
If a TSE repository is added to the extent pool after the ESE volumes are created, the
virtual capacity overhead is removed from the Allocated to ESE repository total and
added to the Allocated to TSE repository total.
The Allocated to ESE repository value includes the total of the overhead space required to
support the current virtual space in all extent pools without a TSE repository, plus the space
used for data written to all ESE volumes in all extent pools. The value indicated will be the
same, regardless of whether ESE repositories exist.
45
Note: Be aware that the virtual capacity of an extent pool requires overhead to support it.
Although the virtual capacity for an extent pool can be set for either TSE or ESE by
creating new volumes (ESE or TSE) or by using the chssestg command and using the
-reptype xxx (ESE or TSE) parameter, there is only one virtual capacity for an extent pool.
If an extent pool contains a TSE repository, the virtual capacity overhead is considered
Allocated to TSE repository. Even if the same extent pool contains ESE volumes, the
virtual capacity overhead from the virtual capacity used for those volumes is considered
Allocated to TSE repository. Only when the repository does not contain a TSE repository
is the virtual capacity overhead considered Allocated to ESE repository.
The first line in the summary provides the amount of storage Available for allocation in the
DS8000. This value includes space assigned for all ESE repositories that exist in the extent
pools that are not currently storing data.
In summary, after the ESE storage is configured (ESE logical volumes created and optionally
ESE repositories created), as data is written to the volumes, the space used for the data
causes the Available for allocation total to decrease and the Allocated to ESE repository
total to increase.
A better way to understand the actual setup in the DS8000 for space-efficient storage is to
use DS CLI commands.
Add space-efficient repository storage in extent pools

The DS GUI will allow the creation of a TSE repository only, although it is referred to as a
space-efficient repository. Also, the DS GUI will provide details for TSE repositories only if
they exist. An ESE repository can only be created and managed by using DS CLI commands.
Figure 5-4 shows the new Add Space-Efficient Repository window where the only two
required inputs are repository capacity (minimum 16 GiB) and the repository capacity
threshold. Notice that there is no type selection available.
Figure 5-4 Add Space-Efficient Repository window
Extent pool properties

The Single Pool Properties window displays additional information for ESE volumes under the
Space-Efficient Storage tab as shown in Figure 5-5 on page 47.
The repository information (capacity, capacity allocated, data state, and configuration state)
relates to TSE volumes only. The total virtual capacity is shown for both TSE and ESE
volumes in that extent pool. Also shown is the allocated ESE physical and virtual capacity.
46
The ESE Virtual Capacity Allocated shows the total virtual capacity of the ESE volumes in the
extent pool. The ESE Physical Capacity Allocated is the amount of space used to store data
in those volumes.
Figure 5-5 Extent pool properties
The Space-efficient Overhead capacity includes the metadata (overhead) space used for the
virtual storage in the extent pool, and the TSE repository overhead if it exists.
When working with ESE volumes, it is best to use the CLI commands so that all the options to
create and correctly manage the volumes are available. The next section provides the CLI
commands that are used to work with ESE volumes.
5.3 DS CLI commands

All of the functions required to create and manage ESE logical volumes are possible through
the use of CLI commands. This section reviews each command that can be used in the
creation and management of ESE logical volumes. Because these commands are not new,
only the parameters and output details that refer to ESE storage are covered.
The following DS CLI commands are reviewed:
mksestg
chsestg
lssestg, showsestg
mkfbvol
lsfbvol, showfbvol
showextpool
initfbvol
lsvolinit (does not show Quick Init)
47
Important: Thin provisioning is not supported for CKD volumes. However, the thin
provisioning parameters are added to CKD DS CLI commands (mkckdvol, lsckdvol,
showckdvol, and initckdvol)as a possible future capability.
The mksestg command

The mksestg command is used to create a space-efficient repository in an existing extent
pool. You can only create one TSE and one ESE repository in an extent pool. After the
repository is created, if you need to change the size, you must use the chsestg command.
The mksestg command can also be used to specify the virtual capacity setting for the extent
pool. Usually this is not necessary because the virtual capacity will automatically increase as
additional space-efficient volumes are created in an extent pool. You cannot decrease the
virtual capacity with this command.
The mksestg command is used to create an ESE repository if you plan to use an ESE
repository for the ESE logical volumes. Other space-efficient parameters can be controlled
with this command. Because the virtual capacity is controlled automatically, only the use of
the command to create the repository is described.
To create an ESE repository, you need to use these parameters:
reptype with the option ese when you want to create an ESE repository. If this parameter
is not specified, it defaults to type tse.
repcap is used to specify the capacity of the repository. Use any value from zero up to the
physical size of the extent pool. The default is zero.
You can increase or decrease the size of the repository later without deleting any ESE
logical volumes.
Note: Although you can specify the -repcap parameter equal to the physical size of the
extent pool (if it is all available), it is not practical to do so. You will not be able to create
any ESE volumes in the extent pool, because no space is available for the virtual
capacity overhead that is required for ESE volumes. Careful planning must be made to
determine how the physical space in an extent pool is to be used, especially when
working with space-efficient volumes.
Example 5-1 shows the use of the mksestg command to create an ESE repository.
Example 5-1 Using the mksestg command to create an ESE repository
dscli> mksestg -reptype ESE -repcap 100 p6

CMUC00342I mksestg: The space-efficient storage for the extent pool P6 has been
created successfully.
Remember these important considerations when you use this command to create an ESE
repository:
The default capacity type is gb (GiB). It is possible to use the captype parameter to
specify a different unit type, such as block. (Only use this if you plan to specify volume
sizes using the block type parameter.)
The actual capacity of the repository will be increased to the next highest whole number
percentage value that represents the repository capacity as a percentage of the physical
capacity of the extent pool. The size of the repository is adjusted automatically to maintain
this percentage if the physical capacity of the extent pool is ever changed.
48
The reppercent parameter is available with this command. This parameter cannot be
used along with the repcap parameter. If you use this parameter, the actual size of the
repository will always be 0 no matter what value is specified.
Because the virtual capacity is managed automatically as the ESE logical volumes are
created, it is not necessary to set the virtual capacity value using the vircap parameter.
The repository can be created either before or after the ESE logical volumes are created.
If it is created after the ESE logical volumes and data is stored in them, the specified size
of the repository must be at least equal to the space currently used to store data in the
ESE logical volumes.
The chsestg command

The chsestg command is used to change the space-efficient attributes for an extent pool.
When working with thin provisioning, the main purpose of using this command is to change
the size of an ESE repository, when an ESE repository already exists.
Example 5-2 shows the use of the command to change the size of the ESE repository.
Example 5-2 The chsestg command used to change repository capacity
dscli> chsestg -reptype ESE -repcap 1000 P5

CMUC00343I chsestg: The space-efficient storage for the extent pool P5 has been
modified successfully.
When changing the ESE size, unless a value of zero is used or the physical capacity of the
extent pool (do not specify), as with the mksestg command, the actual size of the repository is
set to a value equal to the next whole number percentage value.
Note: Designating the size of the ESE repository to be equal to the physical capacity of the
extent pool (assuming it was all available) will not allow you to create any ESE volumes in
the extent pool, because no extents are available for the virtual space overhead.
This command can also be used to change the virtual capacity and the repository thresholds,
but that information is not covered in this paper.
The lssestg command

The lssestg command reports the current space-efficient storage that is set up in the extent
pools using fields to provide specific details. You can select the report for a specific pool or for
all of the pools. Only those pools that have space-efficient storage will be displayed.
If a TSE or an ESE repository exists in an extent pool, the details are provided for the
appropriate repository.
If there is no ESE repository, but there are ESE logical volumes in the extent pool, details are
provided, but most of the fields will be either 0.0 or a dash (-). An optional l parameter
displays additional details, as shown in Example 5-3 on page 50. (To fit the full line of output
on one line, the font is smaller than usual.)
49
Example 5-3 Report from the lssestg command

dscli> lssestg -l
extpool stgtype datastate configstate repcapstatus repcap(GiB/Mod1) vircap reptype repcapalloc vircapalloc opratio
==================================================================================================================
P2
fb
Normal
Normal
0.0 1000.0 0.0
P4
fb
Normal
Normal
below
110.0 1000.0 ese
0.0
1000.0
9.1
P6
fb
Normal
Normal
below
100.0 1000.0 tse
0.0
1000.0
10.0
P8
fb
Normal
Normal
below
100.0 2000.0 tse
0.0
1000.0
10.0
P10
fb
Normal
Normal
below
100.0 2000.0 tse
0.0
1000.0
10.0
P10
fb
Normal
Normal
below
125.6 2000.0 ese
0.0
1000.0
8.0
The output (report) of the command provides important details about the status of the
space-efficient storage and capacity details under the following headings:
stgtype: The type of storage that the extent pool supports. Although it can be fb or ckd for
TSE, for thin provisioning (ESE), only fb storage is supported.
datastate: The state of the extents in the extent pool. Anything other than normal indicates
a likely problem. For a complete listing and explanation of all the possible values for this
field, see the IBM DS8000 Series Command-Line Interface Users Guide, GC27-4212-02.
configstate: The current state of space-efficient configuration operations. When there are
no operations in progress, the state will be normal. All the other states and their meanings
are explained in the IBM DS8000 Series Command-Line Interface Users Guide,
GC27-4212-02.
repcapstatus: The current status of the repository capacity that is available relative to its
threshold. Three threshold settings are possible for a repository: two are
system-controlled settings and the third setting is set by the user.
The two settings that are set by the system are 0% (zero percent) available or 100% full,
and 15% available or 85% full. These two values cannot be changed. The third user
setting is controlled by specifying the repcapthreshold parameter with either the mksestg
command when creating the repository, or with the chsestg command after the repository
is created. This parameter is used to specify the user-defined repository capacity
threshold percentage. By default, the value is set to 0% (zero percent), which is the same
as one of the machine settings.
The status of the user-defined threshold is displayed in this field.
The status can be one of these values:
below: The current available capacity of the repository is below the user-defined
threshold.
exceeded: The current available capacity has exceeded the threshold.
full: The repository has no available capacity.
- (a dash): No repository exists or the status is invalid. This is the case if you create
ESE volumes without an ESE repository.
When any threshold is met or exceeded, a notification is sent so that the customer is
aware of the situation (if the notification is set up).
repcap: The current size of the repository, which can be displayed in GiB (for FB volumes)
or Mod 1 (for CKD) volumes. Thin provisioning (ESE) is only supported for FB volumes.
vircap: The virtual capacity configured for space-efficient volumes in the extent pool. This
value can be increased with the chsestg command after the repository is created. When
an extent pool is created, this value is set to zero. The system automatically updates the
virtual capacity of an extent pool as you create TSE and ESE volumes.
Rather than controlling this value automatically, it can be increased with the chsestg
command with the -vircap parameter. After the increase is complete, the field shows the
value specified in the command.
50
It can also be increased by using the mksestg command with the -vircap parameter, but
only if specifying the default -reptype TSE.
Any subsequent virtual configuration process, such as adding additional space-efficient
volumes to the extent pool, can automatically increase the virtual capacity of an extent
pool, which will be reflected in this field. This will occur when the current virtual capacity is
less that the sum of the virtual capacity of the current space-efficient volumes, plus the
volumes being added.
reptype: The type of volumes that the repository supports, with a possible value of tse,
ese, or a dash (-). The dash indicates that no repositories are in the extent pool, but ESE
volumes are created.
repcapalloc: The capacity in the specific repository that is allocated, which means the
capacity currently storing volume data.
vircapalloc: The total virtual capacity allocated for all the space-efficient volumes in the
extent pool that belong to a repository indicated in the reptype field. If no ESE repository
exists, this field is 0.0.
opratio: The over-provisioned ratio for the repository. For ESE volumes, if no ESE
repository exists, this field is a dash (-). If a repository exists, this value is the total virtual
capacity of the ESE volumes compared to the size of the ESE repository. The lower the
number, the better the situation. For example, if the opratio field has a value of 4.0, the
total virtual capacity of the ESE volumes is four times greater than the capacity of the ESE
repository. (The same ratio applies for a TSE repository.)
Note: For TSE repositories with CKD volumes allocated, the repcapalloc and
vircapalloc fields represent the number of Mod 1 extents used (including tenths). As
well, for these two fields, the command includes an optional parameter percent, which
sets the fields to a percent value, rather than a number value.
There are five scenarios (among others and each scenario is shown in Example 5-3 on
page 50) that can cause the report from this command to provide various values for the vircap
and reptype fields for an individual extent pool:
Only ESE volumes are created without any ESE repository: There is one line in the report
for the extent pool and the vircap value is the total virtual capacity of the ESE volumes in
the pool. (The reptype field is a dash (-). See Example 5-3 on page 50 -- P2.)
Only ESE volumes are created with an ESE repository: There is one line in the report for
the extent pool and this value is the total virtual capacity of all of the ESE volumes in the
extent pool. (The reptype field is ESE. See Example 5-3 on page 50 -- P4.)
Only a TSE repository with TSE volumes is created, and no ESE repository and no ESE
volumes are created: There is one line in the report for the extent pool and this value is the
total virtual capacity of all of the TSE volumes in the extent pool. (The reptype field is tse.
See Example 5-3 on page 50 -- P6.)
A TSE repository with TSE volumes is created, with ESE volumes, but no ESE repository:
There is one line in the report for the extent pool and this value is the total virtual capacity
of the TSE and ESE volumes in the extent pool. (The reptype field is tse. See
Example 5-3 on page 50 -- P8.)
Both a TSE repository with TSE volumes is created and an ESE repository with ESE
volumes is created: There are two lines in the report for the extent pool, one for each
repository with the reptype field indicating the line for the ESE or TSE repository. The total
virtual capacity of both the TSE and ESE volumes in the extent pool is displayed on each
line. When the report includes two lines for an individual extent pool, the virtual capacity
will always be the same in each line. (See Example 5-3 on page 50 -- P10).
51
Note: In each of these scenario descriptions, it is assumed that the virtual capacity is
controlled automatically and that the virtual capacity has not been changed by using either
the chsestg or mksestg command. Although it might seem as though the virtual capacity is
set for a specific type (either TSE or ESE), in reality, it is just the virtual capacity configured
in the extent pool, which can be used for TSE (with a TSE repository) or ESE volumes.
The showsestg command

The showsestg command reports the current space-efficient storage that is set up in a specific
extent pool. For this command, you must specify the -reptype parameter with the value ese
to display the details for an ESE repository. The report for the lssestg command in
Example 5-4 only shows the main details (a few details are omitted for brevity). You must also
specify the extent pool ID in the command.
Example 5-4 shows the report (output) for the showsestg command.
Example 5-4 Report from the showsestg command
dscli> showsestg -reptype ese p10
extpool
P10
stgtype
fb
datastate
Normal
configstate
Normal
repcapstatus
below
%repcapthreshold
0
repcap(GiB)
125.6
repcap(Mod1)
repcap(blocks)
263486176
repcap(cyl)
repcapalloc(GiB/Mod1) 0.0
%repcapalloc
0
vircap(GiB)
2000.0
vircap(Mod1)
vircap(blocks)
4194304000
vircap(cyl)
vircapalloc(GiB/Mod1) 1000.0
%vircapalloc
4
overhead(GiB/Mod1)
9134.4
reqrepcap(GiB/Mod1)
125.6
reqvircap(GiB/Mod1)
210000.0
reptype
ese
opratio
8.0
We explain the additional details that are included in this report that are not included in the
lssestg report:
%repcapthreshold: The current setting of the repository capacity threshold as the
percentage available. As long as the available percentage is higher than this value, the
repcapstatus shows below.
%repcapalloc: The percentage of the ESE repository that is allocated with data.
52
%vircapalloc: The percentage of total vircap indicated (example shows 210000) that is
currently used for ESE logical volumes as shown in vircapalloc (example shows 10000). It
shows 4% in the example, but it is actually 4.75 percent, which is rounded down to a whole
number.
overhead (GiB/Mod1): Although this field is included in the ESE report, it does not provide
any overhead amount for the ESE volumes. Because this field only provides TSE
overhead, if there are no TSE volumes, this field is a dash (-).
The mkfbvol command

The mkfbvol command creates open systems fixed block (FB) volumes in a storage image.
With thin provisioning, the ESE value is added to the storage allocation method (-sam)
parameter. This parameter designates that an ESE logical volume is being configured
(provisioned) with a set of virtual extents that are associated with the space-efficient storage
in the same extent pool.
Example 5-5 shows the mkfbvol command using the storage allocation method (-sam)
parameter with a value of ESE.
Example 5-5 Using the mkfbvol command
dscli> mkfbvol -extpool P4 -cap 10 -type ds -name itsodapa4810 -sam ese 4810
CMUC00025I mkfbvol: FB volume 4810 successfully created.
Note: This command is successful, whether or not an ESE repository already exists. The
virtual capacity is automatically increased if necessary and the available space supports it
in the extent pool. It fails if the virtual capacity is insufficient to support the new volumes.
The lsfbvol and showfbvol commands

The lsfbvol command displays a list of fixed block volumes in a storage image and status
information for each volume in the list.
With thin provisioning support, the ESE value is added to the storage allocation method
(-sam) parameter. This parameter designates that only ESE logical volumes will be displayed.
If you specify the -l parameter, the output will include a sam column and other additional
attributes.
Example 5-6 shows the lsfbvol command using storage allocation method parameter (-sam)
with the ESE value.
Example 5-6 The lsfbvol command
dscli> lsfbvol -sam ese -l
Name
ID
accstate datastate configstate deviceMTM datatype extpool sam captype cap (2^30B) cap (10^9B) cap
====================================================================================================================
Testese
0000 Online
Normal
Normal
2107-900 FB 512
P4
ESE
DS
100.0
Testese
0001 Online
Normal
Normal
2107-900 FB 512
P4
ESE
DS
100.0
Testese
0002 Online
Normal
Normal
2107-900 FB 512
P4
ESE
DS
100.0
Testese
0003 Online
Normal
Normal
2107-900 FB 512
P4
ESE
DS
100.0
Testese
0004 Online
Normal
Normal
2107-900 FB 512
P4
ESE
DS
100.0
Testese
0005 Online
Normal
Normal
2107-900 FB 512
P4
ESE
DS
100.0
Testese
0006 Online
Normal
Normal
2107-900 FB 512
P4
ESE
DS
100.0
Testese
0007 Online
Normal
Normal
2107-900 FB 512
P4
ESE
DS
100.0
See the lsfbvol command help for additional details about the remaining details that are
provided with this command.
53
The showfbvol command displays detailed properties for an individual volume. With thin
provisioning support, the ESE value is shown as a storage allocation method (-sam). The
command also shows the number of virtual extents and the real allocated extents to the ESE
volume.
Example 5-7 shows the output of the showfbvol command for an ESE volume, with the sam
field indicating the type ESE. There are additional lines in the report that are not shown in the
example.
Example 5-7 The showfbvol command
dscli> showfbvol
Name
ID
accstate
datastate
configstate
deviceMTM
datatype
addrgrp
extpool
exts
captype
cap (2^30B)
cap (10^9B)
cap (blocks)
volgrp
ranks
dbexts
sam
repcapalloc
eam
reqcap (blocks)
realextents
virtualextents
....
000a
Testese0
000A
Online
Normal
Normal
2107-900
FB 512
0
P16
100
DS
100.0
209715200
V2
1
0
ESE
managed
209715200
22
100
See the command help report for an explanation of all the fields in this report.
Note: The repcapalloc field will be a dash (-) if the sam field is not tse.
The reports for both the lsbvol and showfbvol commands are the same, regardless of
whether an ESE repository exists in the extent pool to which the volume belongs.
The showextpool command

The showextpool command displays the detailed properties (by default), the detailed
properties with tier distribution (using parameter -tier), or performance metrics of an extent
pool (using parameter -metrics).
The following list of space-efficient related fields in the detailed report for the showextpool
command are shown in Example 5-8 on page 55:
%allocated(ese): Percentage of real space in the extent pool allocated to store data in
ESE volumes, regardless of whether an ESE repository exists in the extent pool.
%allocated(rep): Percentage of real space in the extent pool used for the TSE repository.
54
%allocated(std): Percentage of real space allocated to standard volumes.

%allocated(over): Percentage of real space used for overhead of TSE volumes only.
%virallocated(ese): Percentage of virtual space (as indicated in the virconfigured field)
allocated to ESE volumes
%virallocated(tse): Percentage of virtual space (as indicated in the virconfigured field)
allocated to TSE volumes
%virallocated(init): Percentage of virtual space that is not available (in a sense, allocated)
while it is initialized
Example 5-8 The showextpool command
dscli> showextpool P4
Name
fb_r5_0
ID
P4
stgtype
fb
totlstor (2^30B)
3104
availstor (2^30B)
999
resvdstor (2^30B)
0
rankgrp
0
numranks
8
numvols
116
status
below
%allocated
67
%available
32
configured
3104
allowed
3104
available
999
allocated
2105
reserved
0
%limit
100
%threshold
15
virextstatus
below
%virallocated
8
%viravailable
91
virconfigured
12000
virallowed
12000
viravailable
11000
virallocated
1000
virreserved
0
%virextlimit
100
%virextthreshold
0
encryptgrp
%allocated(ese)
14
%allocated(rep)
11
%allocated(std)
39
%allocated(over)
1
%virallocated(ese) 7
%virallocated(tse) 0
%virallocated(init) 0
55
The detailed extent pool properties output shows important values for real capacity and for
virtual capacity. These values are possible:
configured
The number of total extents configured to the extent pool.
allowed
The number of remaining extents, when a limit has been set. If the limit is disabled or has
been set to 100%, the allowed extent has the same value as the configured extent.
available
The number of free extents that can be allocated either to standard logical volumes, the
TSE repository, or ESE logical volumes, but it currently does not include the ESE
repository. You need to subtract the size of the ESE repository from this number for an
accurate value, as determined by using the lssestg command.
allocated
The number of allocated real extents. It is the sum of extents allocated for these objects:
Standard logical volumes (if they exist)
TSE repository and overhead for the repository (if it exists in the extent pool)
The data written to ESE volumes (if they exist in the extent pool)
The virtual capacity overhead of the extent pool (if there are TSE or ESE volumes)
The initfbvol command

The initfbvol command can be used to initialize a logical volume. As well, for
space-efficient logical volumes, this command can be used to release space by including the
-action releasespace parameter in the command.
For TSE volumes, the action releases tracks in the repository, reducing the repository
allocated space. For example, if a space-efficient logical volume is used as a FlashCopy
target volume and the data stored on those tracks is no longer needed, use the initfbvol
command to free the extents that were assigned to this logical volume. This allows the extents
to be reused by other TSE logical volumes.
For ESE volumes, the action releases extents being used in the extent pool, reducing the
extent pool allocated extents. This allows the extents to be used by either other ESE volumes,
or if no ESE repository exists, other standard volumes.
Important: The initfbvol -action releasespace command deletes all data on the
specified volume.
Example 5-9 illustrates the use of the initfbvol command with the -action parameter.
Example 5-9 The initfbvol command
dscli> initfbvol -action releasespace 4611

CMUC00337W initfbvol: Are you sure that you want to submit the command
releasespace for the FB volume 4611?[Y/N]:y
CMUC00340I initfbvol: 4611: The command releasespace has completed successfully.
56
The lsvolinit command

The lsvolinit command displays volumes that are being initialized using the FlashInit
method. The new Quick Initialization (Quick Init) method is not supported with this command.
5.4 Logical configuration process for ESE volumes

The logical configuration process for ESE volumes is mostly similar to that of standard logical
volumes. An ESE logical volume is configured with a user-specified capacity. The difference
with ESE logical volumes compared to standard logical volumes is that with standard
volumes, the selected extent pool must have available space to support the size of the
standard volumes. However, the available space must only support the overhead space
required for the ESE logical volumes.
All space-efficient volumes use virtual capacity, which requires overhead to support that
capacity. The overhead uses real extents in the extent pool to store metadata required to
support the virtual capacity. When created or expanded, an ESE (or a TSE) logical volume is
allocated using one or more virtual extents from the virtual capacity of the extent pool to
provide sufficient capacity to provision the user-specified capacity. When working with ESE
and TSE logical volumes, the virtual capacity is managed automatically by the DS8000. It can
also be managed manually by using the chsestg command.
When an ESE logical volume is deleted, all real and virtual extents allocated to the logical
volume are released and become available for reallocation. When space is released from an
ESE logical volume, the real extents that are released become available for reallocation.
Note: The overhead required for an ESE logical volume is not deleted when the volume is
deleted because the virtual capacity that the volume was using still exists.
Before you configure an ESE logical volume, one or more extent pools must already be
configured in the DS8000 because the volume uses available capacity in an extent pool. The
storage allocation method attribute ESE must be specified to designate that an extent
space-efficient logical volume needs to be created.
The amount of physical capacity available to provision a set of ESE logical volumes might be
less than the sum of the capacities of all the ESE logical volumes, within an extent pool. This
practice is referred to as storage over-committing or over-provisioning. With ESE volumes, it
is a users responsibility to determine the over-provisioning ratio that is permissible for the
logical volumes that are allocated in a specific extent pool.
The other consideration when configuring ESE logical volumes is whether a repository is
used. The benefits for using an ESE repository are provided in this chapter.
For details about ESE logical volume concepts and implementation, see 3.3, ESE logical
volumes on page 21.
57
5.4.1 Configuring ESE volumes with the DS GUI illustrated

When configuring ESE volumes, if you require the creation of an ESE repository, be aware
that the ESE repository creation is not possible by using the DS GUI. An ESE repository can
only be created by using the mksestg command. This command is not included in the steps in
this procedure. It is included in the next section, which describes the configuration steps using
DS CLI commands.
These procedures and screen captures are based on the DS GUI using the icon navigation
option.
Creating ESE volumes

Follow these steps to create ESE volumes using the DS GUI without an ESE repository:
1. Place the mouse over the Volumes icon and click FB Volumes in the pop-up window. This
opens the FB Volumes window as shown in Figure 5-6.
Figure 5-6 FB Volumes window
If you have more than one storage image, select the appropriate one at the top of the
window. This is not shown in the figure.
From the Tasks pane at the bottom of the window, click Create new volumes. The Create
Volumes window (Figure 5-7 on page 59) opens.
58
Figure 5-7 Create Volumes window
2. In the Create Volumes window, select one or more of the existing extent pools in which you
want to create volumes. If you choose more than one pool, the volume assignment option
will apply. You must select the correct option to match your requirements.
Note: You can only select more than one extent pool if the pools are sequential.
When you create ESE logical volumes, include these considerations for extent pool
selection:
The virtual capacity available in the extent pool to support the virtual size of the volume
size. The amount included in the column Total Virtual GiB is the current setting and
not necessarily the amount that can be set. If no space-efficient logical volumes are
currently in the extent pool, this value will be 0 (zero). As you create the volumes, the
virtual capacity will automatically increase up to the maximum allowed. The maximum
allowed is determined by the amount of available space in the extent pool for overhead
data that is required to support space-efficient volumes. If you try to create more ESE
logical volume capacity than the extent pool allows, it will fail.
The anticipated amount of data to be written to the volume. If an ESE repository exists
in the extent pool, its size will determine the amount of space available for the written
data. Note that the displayed column Available Repository GiB only displays TSE
repository details. If no ESE repository exists, all of the available extent pool space can
be used for ESE logical volume data.
The overhead space required to support the virtual space of the ESE logical volumes
that you are creating. This space uses real extents, and is approximately .45% of the
virtual volume capacity. If no ESE repository exists and if you use the maximum
allowed capacity of an extent pool for the ESE logical volumes, the overhead will use
up all the available space in the extent pool, so that no data can be written to the
volumes.
Spreading the volumes across different servers for a balanced configuration. This
assumes that you have extent pools that are assigned to both servers 0 and 1. The
displayed column Server shows the server that is managing the extent pool volumes.
59
After you select the correct extent pools, click Next. The Add Volumes window (Figure 5-8)
opens.
Figure 5-8 Add Volumes window
There are three sections to the Add Volumes window. In the Define Volume
Characteristics section at the top (see Figure 5-8), select the Storage allocation method
(sam) Extent Space Efficient (ESE). This will set the Available Capacity value shown at
the top of the window to the available virtual capacity in the extent pools selected.
Remember that this value can be slightly higher than what you can actually create. Then,
specify the size (which is the virtual size) and quantity of volumes that you want to create.
You can change the Volume type from the default FB Volumes - DS, if necessary. The
Extent allocation method only applies to standard sam volumes. Select an appropriate
Priority Group and Resource Group setting, if required.
Complete the Optionally Choose Nickname section if you do not want the default values to
be used.
Finally, complete the Optionally Assign Volume Groups section where you can either
select a volume group that already exists to which to add these volumes, or you can create
a new volume group to which to add them. This can also be done later after the volumes
are created.
When your settings are complete, you can either click Add Another to create more
volumes, or click OK. In this example, we click OK. The Create Volumes window reopens,
as shown in Figure 5-9 on page 61.
Important: The amount of projected remaining capacity for ESE volumes is based on
the values that you specify for the Size and Volume Quantity fields. It shows the
remaining virtual capacity that can be allocated.
The DS8000 creates the virtual capacity automatically before it creates the ESE
volumes. If you accidentally use all remaining capacity, your extent pool will be full.
60
Figure 5-9 Create Volumes window
3. Now, you can select the displayed volume information and from the Action pull-down list,
click Modify, if you want to change the settings, or Delete, if you want to delete the
settings. You can also click Add, if you want to add additional volumes to the extent pools
that were selected. If the entries are correct as displayed, click Next at the bottom of the
window. The Create Volumes Select LSS window opens as shown in Figure 5-10.
Figure 5-10 Select LSS
4. In the Select LSS window, you can assign the volumes to a logical subsystem (LSS) using
either the Automatic method, which is the default, or Manual method. If the automatic
method is used, the volumes will be assigned to the first LSS in the list until all available
addresses are used and then it continues to the next LSS in the list. If you select the
manual method, you need to select the specific LSSs to use. Click Finish.
5. The Create Volumes Verification window (Figure 5-11 on page 62) opens, listing all the
volumes that will be created. Depending on the number of volumes, the process might
take time to complete. You can use the actions available to make changes to the settings,
or add additional volumes.
61
Figure 5-11 Create Volumes Verification
6. Click Create All to create all the volumes. If a failure occurs, the volumes will not be
created.
After the creation is complete, an updated FB Volumes window opens. You can select View
detail or Close. If you click Close, you are returned to the FB Volumes window. From there,
you can now execute other actions, such as Manage Existing Volumes. By using the Filter by:
Storage Allocation Method option, you can select ESE to display ESE volumes (Figure 5-12).
Figure 5-12 Displaying ESE volumes
The steps to create ESE logical volumes by using the DS GUI are complete.
Managing ESE volumes by using the DS GUI

The correct ESE volume management requires that you monitor and track your capacity
utilization for both virtual and real capacity (especially when there is no ESE repository). It is
your responsibility to manage the capacity. Chapter 6, Managing and monitoring
thin-provisioned volumes on page 75 provides information about various monitoring tools.
62
With the DS GUI, you can monitor and manage the capacity by using the Internal
Storage-Extent Pools and FB volumes windows. They include the following elements:
Internal Storage-Extent Pools:
Properties
Virtual and physical capacity allocated
Thresholds
Add or remove capacity to extent pool
Add space-efficient repository
Delete space-efficient storage
FB volumes:
Properties
Increase capacity
Initialize
Delete

The Internal Storage window and Extent Pools tab are used to analyze the current storage
status and initiate associated extent pool processing that includes space-efficient storage
designation for a selected storage image.
The bar chart shows a graphical comparison between the assigned total storage capacity and
the total available capacity for open systems volumes (standard and space-efficient volumes ESE and TSE) and for System z volumes (CKD). The chart gives you a quick overview of the
storage allocation in your DS8000.
Note: The summary on the right side of the window includes the total amount of allocated
GiB to TSE and ESE repositories. It is important to know that these two values do not
indicate the size of the repositories.
The Allocated to TSE repository value includes the sum of these objects:
TSE repositories in the DS8000
Overhead required for the TSE repositories in the extent pools
Overhead required for the virtual space in the extent pools that include a TSE
repository
The Allocated to ESE repository value includes the sum of these objects:
Overhead required for the virtual space in the extent pools that do not include a TSE
repository
Data written to the ESE volumes in the extent pools
The Allocated to ESE repository value does not include the ESE repository space, if
used in any extent pool.
The Available for allocation space includes unused ESE repository space, because ESE
repositories are not allocated. (TSE repositories are allocated.)
63
The window also displays alerts for various exceeded threshold conditions and other states
that might exist. Alerts help you manage the capacity. The following alerts can be displayed:
Pools with physical threshold exceeded
Specifies that one or more extent pools have exceeded the current physical threshold
setting. The default value is 100.
Pools with virtual storage threshold exceeded
Specifies that one or more extent pools have exceeded the current virtual capacity
threshold setting. The default value is 100.
Pools with TSE repository capacity threshold exceeded
Specifies that one or more extent pools have exceeded the current repository capacity
threshold setting. The default value 100.
Pools with ranks in abnormal state
Specifies that one or more extent pools have one or more ranks in an abnormal state. For
example, a rank is in a degraded state or another error condition has occurred.
Pools with TSE repository in abnormal state
Specifies that one or more extent pools have one or more repositories in an abnormal
state.
Figure 5-13 shows the Internal Storage window with the Extent Pools tab.
Figure 5-13 Extent pool summary
By selecting an extent pool, you can check its properties or perform other actions, such as
adding and removing capacity.
The DS GUI provides no monitoring of ESE repositories in extent pools. An ESE repository
cannot be created by using the DS GUI, and no details about them are provided in the DS
GUI if they exist. If you need to know the status of an ESE repository, you must use the
lssestg and showsestg DS CLI commands.
64
When you have ESE logical volumes in an extent pool without an ESE repository, the only
monitoring that occurs concerns the extent pool utilization. As more data is written to the ESE
volumes in the pool, the percentage of available extents will continue to decrease. When the
threshold percentage for the extent pool is reached, a Physical Storage Threshold
Exceeded alert will be provided in the Internal Storage window, with the extent pool status
indicating Threshold Exceeded. When the percentage of available extents reaches zero, the
alert remains, but the extent pool will have a status of Full.
FB Volumes page
The FB Volumes main page is used to analyze open systems storage information and initiate
actions that relate to open systems volumes. It shows the amount of standard capacity and
virtual capacity for ESE and TSE logical volumes. It also shows alert information for different
error messages (Figure 5-6 on page 58).
Two type of alerts can appear for FB volumes: volumes with status errors and volumes
with a migration status.
Select Manage existing volumes in the Task area to open a window where you can manage
open systems volumes. By using the filter option, you can display only ESE volumes, and by
selecting one or more volumes, you can increase capacity, initialize a volume, add a volume
to a volume group, or delete a volume. You can also check the properties of each volume.
Expanding an ESE volume by using DS GUI

An existing ESE logical volume can be expanded by using DS GUI by specifying a new
requested capacity. If no virtual extents are available to expand an ESE volume, DS Storage
manager GUI expands the virtual capacity automatically.
Note: 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.
Follow these steps to expand an ESE volume:
1. In the DS GUI welcome window, with your mouse over the Volumes icon, click FB
Volumes. This action opens the FB Volumes window (Figure 5-6 on page 58). Click
Manage existing volumes and the Manage Volumes window (Figure 5-14) opens.
Figure 5-14 Manage Volumes window
65
To locate the volume, you can use the Filter by box and select Storage Allocation
Method. Select ESE in the Select Storage Allocation Method box as shown in the
example.
2. Select your ESE volume and in the Action menu, select Increase capacity, which opens
the Increase Capacity window (Figure 5-15).
Note: The available capacity is indicated based on the available extents in the extent
pool.
Figure 5-15 Increasing volume capacities
Next, working with ESE logical volumes and DS CLI commands is described.
5.4.2 Configuring ESE volumes with the DS CLI illustrated

Before you configure an ESE logical volume, at least one extent pool must already be
configured in the DS8000. When an ESE logical volume is configured, it is always associated
with only one extent pool. The storage allocation method attribute (SAM) ESE must be
specified to indicate that an extent space-efficient logical volume is to be created.
There is now an option to use an ESE repository when you create ESE logical volumes in an
extent pool. This illustration will include the creation and use of a repository with the volumes.
Although you can create the repository before or after the volumes are created, we begin with
creating the repository and then the volumes.
Creating an ESE repository

To create an ESE repository, you must decide its capacity based on the available extents in
the extent pool where it will be created. Remember that because the volumes have not been
created yet (which is our choice in this procedure), overhead space will be required for them,
so do not use the total available space in the extent pool for the size of the repository.
When you specify the size of the repository, the -repcap parameter is used to specify a value
in GiB. The actual repository capacity will be larger than what you specify, because it will be
created with a capacity that is a whole number as a percentage of the physical size of the
extent pool.
The DS CLI command that is used to create an ESE repository is the mksestg command. This
command is the same command that is used to create a TSE repository. With this command,
you need to include the capacity for the repository and the extent pool in which it will be
created. Example 5-10 on page 67 shows an example of using the command to create a 500
GiB ESE repository.
66
Example 5-10 Creating the ESE repository
dscli> mksestg -reptype ese -repcap 500 p16

CMUC00342I mksestg: The space-efficient storage for the extent pool P16 has been
created successfully.
To verify the actual size of the repository, use the lssestg command as shown in
Example 5-11. Note that the actual size of the repository is 509 GiB, which is 24% of the
physical size (2121 GiB) of the extent pool.
Example 5-11 Displaying ESE repository details with the lssestg command
dscli> lssestg -l p16

extpool stgtype datastate configstate repcapstatus repcap(GiB/Mod1) vircap reptype
==================================================================================
P16
fb
Normal
Normal
below
509.0
0.0 ese
The vircap (virtual capacity) of the extent pool is still at the initial value of 0 GiB and will
remain at that value until space-efficient volumes are created.
Another command that you can use to display the details of the ESE repository is the
showsestg command as shown in Example 5-12. You must include the -reptype parameter
with the value ese for the report to provide the details of the ESE repository, because the
default value of this parameter is TSE.
Example 5-12 Displaying ESE repository details with the showsestg command

extpool
P16
stgtype
fb
datastate
Normal
configstate
Normal
repcapstatus
below
%repcapthreshold
0
repcap(GiB)
509.0
repcap(Mod1)
repcap(blocks)
1067534208
repcap(cyl)
%repcapalloc
0
vircap(GiB)
0.0
vircap(Mod1)
vircap(blocks)
0
vircap(cyl)
%vircapalloc
0
overhead(GiB/Mod1)
reqrepcap(GiB/Mod1)
509.0
reqvircap(GiB/Mod1)
0.0
reptype
ese
opratio
0.0
Note: No overhead exists with the creation of the ESE repository. However, overhead
exists when a TSE repository is created.
67
Creating ESE logical volumes

To configure an ESE logical volume by using the mkfbvol command requires virtual extents in
the extent pool to support the logical volume. When an extent pool is created, the number of
virtual extents is zero. As space-efficient volumes are created, virtual extents will be created
automatically by the DS8000 up to the maximum allowed in the extent pool to support the
volumes that are being created.
Example 5-13 shows the creation of an ESE logical volume by using the mkfbvol command
with the -sam parameter that indicates that it will be an ESE logical volume. The last
parameter of 000a is the volid. The volid consists of the LSS identifier and the volume number
of the LSS. The LSS identifier range is 00 - FE. The volume number range is 00 - FF. The left
00 is the LSS ID and the right 0a is the eleventh volume of the LSS. (Ensure that the specified
volid is not already used for an existing volume.) The volume virtual capacity is 1000 GiB and
is allocated in extent pool p16. Also, the showfbvol command report for the volume that is
created is included in the example.
Example 5-13 Configuring ESE logical volume
dscli> mkfbvol -extpool p16 -cap 1000 -name Testese001 -sam ese 000a
CMUC00025I mkfbvol: FB volume 000A successfully created.
dscli> showfbvol
Name
ID
accstate
datastate
configstate
deviceMTM
datatype
addrgrp
extpool
exts
captype
cap (2^30B)
cap (10^9B)
cap (blocks)
volgrp
ranks
dbexts
sam
repcapalloc
eam
reqcap (blocks)
realextents
virtualextents
migrating
perfgrp
migratingfrom
resgrp
tierassignstatus
tierassignerror
tierassignorder
tierassigntarget
%tierassigned
68
000a
Testese001
000A
Online
Normal
Normal
2107-900
FB 512
0
P16
1000
DS
1000.0
2097152000
0
0
ese
managed
2097152000
0
1000
0
PG0
RG0
Unknown
Unknown
Unknown
-1
With the extent pool having the volume allocated, virtual extents are now allocated that equal
the size of the volume. This happens automatically. Now, because of the allocated ESE
volume, look at the repository and extent pool details again by using the lssestg and
showsestg commands. Example 5-14 shows the lssestg -l command for extent pool p16.
Note that the repository has no used capacity (repcapalloc), because the volume has not
been initialized yet and no data has been written to it. But, the virtual capacity (vircap) is now
1000 GiB, which happened automatically. The virtual capacity allocated (vircapalloc) is also
1000 GiB because the volume has been allocated. Also, the opratio shows an
over-provisioned ratio of 2.0. This calculation is the virtual capacity of 1000 GiB can use real
capacity in the ESE repository of 509 GiB, which is approximately two to one. (The text is
smaller to fit the report on one line.)
Example 5-14 The lssestg command with ESE volume allocated
==================================================================================================================
P16
fb
Normal
Normal
below
509.0 1000.0 ese
0.0
1000.0
2.0
The showsestg command report is shown in Example 5-15.

Example 5-15 The showsestg command with ESE volume allocated

extpool
P16
stgtype
fb
datastate
Normal
configstate
Normal
repcapstatus
below
%repcapthreshold
0
repcap(GiB)
509.0
repcap(Mod1)
repcap(blocks)
1067534208
repcap(cyl)
%repcapalloc
0
vircap(GiB)
1000.0
vircap(Mod1)
vircap(blocks)
2097152000
vircap(cyl)
%vircapalloc
100
overhead(GiB/Mod1)
reqrepcap(GiB/Mod1)
509.0
reqvircap(GiB/Mod1)
1000.0
reptype
ese
opratio
2.0
Note that the %vircapalloc is at 100% because all of the virtual extents (1000) have been
allocated for the volume of size 1000 GiB. Also, the overhead shows a dash (-) because this
is the TSE storage overhead, not the ESE storage overhead.
There is ESE volume overhead, which is indicated in the showextpool command as shown in
Example 5-16 on page 70. Here, the %allocated (over) field is again zero, because this field is
only for TSE volumes.
69
The allocated field now shows 5. This is the allocated space (5 GiB) used as overhead for the
ESE logical volume that is allocated. When working with ESE logical volumes, the overhead
is automatically increased as additional volumes are allocated. It is not possible to increase
the virtual capacity of the extent pool if only ESE logical volumes are in the extent pool.
The availstor and available fields now indicate that the extpool pool has 2116 available
extents, because the 5 that are allocated are being used for virtual capacity overhead.
Note: The ESE repository is not included in the allocated space and is still included in the
available space even though it was set up using 509 extents. (Because the ESE repository
can be deleted, its space is not considered allocated.)
With the inclusion of the ESE repository, the available space is really 1607 extents.
Example 5-16 The showextpool command with ESE volume allocated
dscli> showextpool p16

Date/Time: February 10, 2014 2:05:17 PM
Name
TesteseP16
ID
P16
stgtype
fb
totlstor (2^30B)
2121
availstor (2^30B)
2116
resvdstor (2^30B)
0
rankgrp
0
numranks
1
numvols
1
status
below
%allocated
0
%available
99
configured
2121
allowed
2121
available
2116
allocated
5
reserved
0
%limit
100
%threshold
20
virextstatus
full
%virallocated
100
%viravailable
0
virconfigured
1000
virallowed
1000
viravailable
0
virallocated
1000
virreserved
0
%virextlimit
100
%virextthreshold
0
encryptgrp
%allocated(ese)
0
%allocated(rep)
0
%allocated(std)
0
%allocated(over)
0
%virallocated(ese) 100
%virallocated(tse) 0
%virallocated(init) 0
70
%migrating(in)
%migrating(out)
numtiers
etmanaged
0
0
1
yes
The virconfigured, virallowed, and virallocated settings of 1000 are automatically set when the
ESE volume is created (assuming that there is no TSE storage setup) because the volume
size is 1000 GiB. The total virtual configured is also allocated, so the viravailable is 0 (zero).
In this example, while data is written to the volume, we can increase the size of the ESE
repository up to the size of the ESE volume; however, this action requires that the real
available space allows the increase. There are a number of changes that can reduce the
available space in an extent pool:
Adding ESE volumes

Increasing the size of the current ESE volumes
Adding TSE volumes, which also requires a TSE repository
Adding standard volumes
The extent pool opratio will increase if you add ESE volumes or increase the size of the
current ESE volumes. In Example 5-17, with the second volume allocated, the vircap and
vircapalloc now show 2000 GiB, and the opratio is now 3.9. The opratio doubled because the
virtual capacity doubled, but the repository capacity was unchanged.
Example 5-17 Adding additional ESE volumes
dscli> mkfbvol -extpool p16 -cap 1000 -name TestESE002 -sam ese 000b
CMUC00025I mkfbvol: FB volume 000B successfully created.
==================================================================================================================
P16
fb
Normal
Normal
below
509.0 2000.0 ese
0.0
2000.0
3.9
Although not shown, the showextpool command now shows 9 allocated extents and available
extents of 2112. The 9 allocated extents are the overhead (virtual capacity overhead) for the
two ESE volumes that are now allocated.
If this procedure omits the creation of an ESE repository, the report for the showextpool
command is the same. The showsestg -reptype ese command will show that space-efficient
storage does not exist in the extent pool. The lssestg command only provides the virtual
capacity (vircap) and virtual capacity allocated (vircapalloc) fields with data.
Using ESE logical volumes

Now, we initialize an ESE volume and add files to the ESE volume, and then review these
commands to view the repository details. The assignment of the volume to a volume group,
the initialization of the volume, and writing files to the volume on a host are not shown. With
these steps completed, Example 5-18 shows the lssestg command report, which indicates
that repository space was allocated (repcapalloc).
Example 5-18 The lssestg command showing that repository space was allocated
Date/Time: February 10, 2014 2:45:02 PM EST IBM DSCLI Version: 7.7.30.163 DS: IBM.2107-75ZA571
==================================================================================================================
P16
fb
Normal
Normal
below
509.3 2000.0 ese
30.0
2000.0
3.9
71
After an ESE volume is initialized, and files are written to it, space in the ESE repository will
be allocated to store the data. The repcapalloc field will show the total space used in the
repository to store data for all the ESE volumes in the extent pool. This usage is also
displayed in the report for the showsestg (repcapalloc) command as shown in Example 5-19,
and the showextpool (allocated) command as shown in Example 5-20.
Example 5-19 The showsestg command with data stored on ESE volume

...
%repcapalloc
5
vircap(GiB)
2000.0
vircap(Mod1)
vircap(blocks)
4194304000
vircap(cyl)
%vircapalloc
100
overhead(GiB/Mod1)
reqrepcap(GiB/Mod1)
509.3
reqvircap(GiB/Mod1)
2000.0
reptype
ese
opratio
3.9
Example 5-20 The showextpool command with data stored on the ESE volume
dscli> showextpool p16

...
totlstor (2^30B)
2122
availstor (2^30B)
2083
resvdstor (2^30B)
0
rankgrp
0
numranks
1
numvols
2
status
below
%allocated
1
%available
98
configured
2122
allowed
2122
available
2083
allocated
39
reserved
0
%limit
100
%threshold
0
virextstatus
full
%virallocated
100
%viravailable
0
virconfigured
2000
virallowed
2000
viravailable
0
virallocated
2000
virreserved
0
%virextlimit
100
%virextthreshold
0
encryptgrp
72
%allocated(ese)
%allocated(rep)
%allocated(std)
%allocated(over)
%virallocated(ese)
%virallocated(tse)
%virallocated(init)
...
1
0
0
0
100
0
0
Note that the allocated amount of 39 includes the overhead of 9 plus the repository allocated
space of 30, which is used to store the current written data on the ESE volumes.
The %allocated and %allocated(ese) are the percentages allocated of the total extent pool
capacity, not the ESE repository capacity.
If there is no ESE repository, the lssestg command does not show any usage. The
showextpool command shows the usage with the available field reduced and the allocated
field increased while extents are used to store data on the volumes using available extents in
the extent pool as shown in Example 5-20 on page 72. The showsestg command does not
accept the -reptype ese parameter without an existing ESE repository.
Managing ESE volumes using DS CLI

With the DS CLI, you can monitor and manage the capacity of extent pools, space-efficient
storage, and ESE volumes. You can also change the real and the virtual capacity of extent
pools, space-efficient storage, and ESE volumes.
Use the following commands for monitoring and management:
List commands: lsextpool, lsfbvol, and lssestg
Show commands: showextpool, showfbvol, and showsestg
Change commands: chextpool, chfbvol, and chsestg
For information about these commands, see 5.3, DS CLI commands on page 47. Detailed
information about the commands is in the DS8000 Command-Line Interface Users Guide,
GC27-4212.
Note: Monitoring and management involve the threshold settings for the extent pool.
Monitoring is determined by whether an ESE repository exists.
When using ESE logical volumes without a repository, there is only monitoring status for the
extent pool. As more data is written to the volumes, the available extents in the pool are
reduced. As long as the extent pool is under the threshold, the status shows below. After the
extent pool gets above the extent pool threshold, the extent pool status indicates exceeded. If
all extents in the pool are used, the pool status shows full. At this point, no more data can be
added to the ESE logical volumes in the extent pool. This status is shown in the report
(output) of the showextpool and lsextpool commands. The default setting for the extent pool
threshold is 100% (0 in the showextpool report for %threshold). You can set the extent pool
threshold when you create the extent pool, or after the extent pool is created by using the
chextpool command.
73
When you use ESE logical volumes with a repository, the monitoring status for the repository
is important, even though the extent pool monitoring also exists. As long as the amount of
allocated extents in the ESE repository is under the threshold, the repcapstatus (repository
capacity status) indicates below. After the amount of allocated extents in the ESE repository
gets above the ESE repository threshold, the repcapstatus indicates exceeded. If all extents in
the ESE repository are used, the repcapstatus indicates full. At this point, no more data can
be added to the ESE logical volumes in the extent pool. The repcapstatus is provided in the
output of the lssestg and showsestg commands. The default repository threshold is 100% (0
in the report for %repcapthreshold). You can set the default repository threshold when you
use the mksestg command, or after the repository is created by using the chsestg command.
If the available space in the repository is getting low, it might be possible to free used space if
you know that files have been removed from the ESE logical volumes, and you no longer
need the data. Use the initfbvol command and specify the -action freespace parameter.
Expanding ESE volumes using DS CLI

To expand the ESE logical volume virtual capacity in an extent pool, the DS8000
automatically increases the virtual capacity of the extent pool, up to the maximum allowed for
the extent pool. Example 5-21 shows the expansion of an existing ESE volume. In this
example, the volume was not yet initialized, so the change will not affect a host operating
system.
Example 5-21 Expanding an ESE volume
==================================================================================================================
P16
fb
Normal
Normal
below
509.0 2000.0 ese
0.0
2000.0
3.9
dscli> chfbvol -cap 1500 000a
CMUC00332W chfbvol: Some host operating systems do not support changing the volume size. Are you sure that you want
to resize the volume? [y/n]: y
CMUC00026I chfbvol: FB volume 000A successfully modified.
==================================================================================================================
P16
fb
Normal
Normal
below
509.0 2500.0 ese
0.0
2500.0
4.9
One of the effects of this change is that the overhead increases. This increase reduces the
amount of available space in the extent pool. In this case, the overhead amount went from 9
to 12 GiB, which reduced the available extents by 3, as indicated in the showextpool
command (not shown).
74
Chapter 6.
Managing and monitoring

thin-provisioned volumes
This chapter describes the DS8000 monitoring and management capabilities for the Thin
Provisioning and space-efficient FlashCopy features.
In general, the complete set of management capabilities is described in this chapter for both
types of space-efficient implementations in the DS8000: extent space-efficient (ESE) and
track space-efficient (TSE). You can obtain more details about the TSE implementation for
IBM FlashCopy SE in IBM System Storage DS8000 Series: IBM FlashCopy SE, REDP-4368,
and in Chapter 3, Space-efficient volumes in the DS8000 on page 17.
75
6.1 Management and monitoring capabilities

Important: In the DS8000, thin provisioning and the associated virtual capacity are
manageable at the extent pool level.
6.1.1 Options to reserve space and buffer capacity

Figure 6-1 on page 77 shows an extent pool with its associated real capacity, virtual capacity,
and repository capacity. The two important options to reserve contingency capacity are extent
limit and reserve ranks. They apply to real capacity (real extents):
Extent limit
This option allows you to limit the percentage of real extents that can be allocated to
logical volumes in an extent pool. The remaining percentage of real extents is therefore
reserved as a contingency buffer for allocation to logical volumes of all types. The extent
limit can be adjusted as required using the DS CLI or GUI.
Reserve ranks
This option allows you to reserve the unallocated capacity of an entire rank in an extent
pool for future use, making the reserved capacity unavailable for allocation to logical
volumes of all types. This capability works both for entire ranks but also for the remaining
unallocated capacity of ranks in an extent pool, because all existing allocations remain
unchanged and are not affected by this command. The reserve ranks can be dynamically
switched on and off using the chrank command. This capability allows you to release
some reserve space for usage, as required. Use this sequence of operations:
a. Release a rank (or the unused parts of the rank).
b. Use the free extents, for example, to create a volume.
c. Reserve the unused space of the rank again.
Important: The larger value of these two options (extent limit and reserve ranks)
determines the baseline, from which the threshold for real capacity (-realcap) is starting to
count.
Capacity on Demand (CoD) feature

This optional, chargeable feature that you can order for the DS8000 provides physical
capacity in terms of drive sets (16 disks) to be installed in the DS8000 for future usage. New
capacity can be brought online by acquiring and entering a license key without any further
activity at the physical level. The new capacity can be configured according to the needs in
terms of RAID levels and storage type. The new capacity can be assigned to all matching
extent pools where capacity is needed.
6.1.2 Options to set thresholds and receive warnings

The detailed description to set up the thresholds using DS CLI or GUI is in Chapter 5, DS
GUI and DS CLI support for thin provisioning on page 41.
Figure 6-1 on page 77 shows that three possible thresholds can be set for the real capacity,
repository capacity, and virtual capacity.
76
Figure 6-1 Extent pool real, repository, and virtual capacity: Reserve buffer and set threshold options
Simple Network Management Protocol (SNMP) warnings are triggered when the amount of
allocated capacity exceeds any of the specified thresholds. A threshold status changes and
can be monitored.
Important: The status levels and warning messages are listed:
Status = 0/Below. Below threshold Available space > Threshold is good.
Status = 1/Exceeded. Warning Available Space is between Threshold and zero.
Status = 10/Full. Space is zero There is no Available Space in the Extent Pool.
In a DS8000 with Licensed Machine Code (LMC) 5.4.3x.xx installed, the thresholds are set to
15% by default. Upgrading the LMC to that level also changes the thresholds on existing
systems to the new default value of 15% (default was 0% on all earlier LMC levels).
Real capacity threshold: -extent_threshold_percentage

The extent threshold specifies a percentage of available space, or available extents, in the
extent pool. It is client configurable between 0% and 100% by using the extent pool command
chextpool. As shown in Figure 6-1, all three volume types and virtual capacity can contribute
to changes in the number of free extents:
Standard volumes when created or deleted.
ESE volumes when real data extents are assigned as necessary, or when their extents are
released again (through initialization, SCSI format unit, or volume deletion).
TSE volumes when their repository is created or deleted.
Virtual capacity when created or increased or through deletion. In virtual capacity,
associated metadata uses real extents in the extent pool.
Chapter 6. Managing and monitoring thin-provisioned volumes
77
Repository capacity threshold: - repository_threshold_percentage

This threshold specifies the minimum percentage of available physical repository capacity. If
the available, free capacity in the repository drops below the percentage value, warnings are
sent and the status changes. It is client configurable between 0% and 100% by using the
commands related to space-efficient storage, such as chsestg.
The repository threshold is unique because it has two fixed thresholds set by the system.
These thresholds cannot be changed: 0% (Repository full) and 15% (Repository 85% full).
For both system set thresholds, SNMP warnings are sent every 5 minutes when exceeded
(but the status reported for the repository is based on the threshold that was configured by the
client).
Virtual capacity threshold: -virtual_extent_threshold_percentage

This threshold is the same as the real extent threshold. A threshold can be set to receive
warnings when the available virtual capacity drops below a certain limit. But, in this case, all
changes to the available virtual capacity must be triggered explicitly by the user, so this
threshold is not as important as the other thresholds.
6.1.3 SNMP trap: Extent pool threshold

The DS8000 can trigger SNMP traps. A new event trap (event trap 223) was introduced with
the Thin Provisioning feature.
The trap is sent when certain extent pool capacity thresholds are reached and cause a
change in the extent status attribute:
Extent status is not zero (available space already below threshold) when the first ESE
volume is configured.
Extent status changes state if ESE volumes are configured in the extent pool.
Example 6-1 shows an illustration of generated event trap 223.
Example 6-1 Specific event trap 223
2009/08/01 17:05:29 PDT
Extent Pool Capacity Threshold Reached
UNIT: Mnf Type-Mod SerialNm
IBM 2107-922 75-03460
Extent Pool ID: P1
Limit: 95%
Threshold: 95%
Status: 0
The extent status attribute is set to a value based on the comparison between extent
threshold and the percentage of remaining available real capacity in the extent pool. The
extent status value is set as depicted in Table 6-1.
Table 6-1 Extent status attribute value
78
Extent status
Description
Condition
10
%Available Real Cap. = 0
Full - extent pool full
Ext. Threshold >= %Avail. Real Cap. > 0
Exceeded - threshold exceeded
%Avail. Real Cap. > Ext. Threshold
Below - below threshold
SNMP traps and their destination (SNMP manager) can be set using the DS CLI.
Example 6-2 is an illustration.
Example 6-2 Setting the SNMP trap and destination
dscli>chsp -snmp on snmpaddr 9.155.87.211,9.155.66.14,9.145.243.185 -desc "ATS

DS8000 S/N 75-20780" -name ATS_Mainz_20780
Date/Time: August 13, 2009 12:51:07 PDT IBM DSCLI Version: 5.4.30.244 DS:
IBM.2107-7520781
Storage-complex IBM.2107-7520781 successfully modified.
dscli> showsp
Date/Time: August 13, 2009 12:51:57 PDT IBM DSCLI Version: 5.4.30.244 DS: Name
ATS_Mainz_20780
desc
ATS DS8000 S/N 75-20780
acct
SNMP
Enabled
SNMPadd
9.155.87.211,9.155.66.14,9.145.243.185
emailnotify
Disabled
emailaddr
emailrelay
Disabled
emailrelayaddr emailrelayhost numkssupported 4
The following examples are software that can be used to manage and monitor
thin-provisioned volumes:
IBM Tivoli Storage Productivity Center supports thin-provisioned volumes by marking
them clearly with an asterisk.
IBM Tivoli Enterprise Console can be set up to receive the SNMP traps sent by the
DS8000 and trigger the necessary actions.
Any other system management and monitoring tools that can receive SNMP traps are
supported.
6.1.4 Managing out-of-space situations

Over-provisioning or over-commitment of capacity can result in a situation where the needed
capacity exceeds the available capacity. In the DS8000 implementation of thin provisioning,
only the amount of data that can actually be written to disk, therefore for which real disk
capacity exists, is accepted for a write operation by the host. For write operations exceeding
this amount, a write inhibit is sent to the host, which typically causes the software to fail. The
DS8000 rejects write accesses to the affected volumes until the required additional real
capacity is made available for allocation.
The options to provide contingency capacity that are described in 6.1.1, Options to reserve
space and buffer capacity on page 76 and the warnings that are received that relate to the
set thresholds can help you avoid an out-of-space situation. However, when these options are
exhausted, the following options still exist to release space on ESE volumes:
Issue SCSI format unit command from the host.
Issue release space request through DS CLI or GUI.
Delete or remove the ESE volume.
Chapter 6. Managing and monitoring thin-provisioned volumes
79
The virtual capacity that is associated with TSE and ESE volumes must be created or
expanded through the DS CLI or GUI as needed to create space-efficient volumes. The
virtual capacity determines the over-commitment ratios for TSE and ESE and therefore needs
to be carefully planned. The virtual capacity also needs to be monitored over time, because it
cannot be easily reduced when created. Virtual capacity can only be deleted when no ESE or
TSE volumes are configured in the extent pool.
80
Chapter 7.
Host considerations and

migration to ESE volumes
This chapter presents our observations of the DS8000 thin provisioning behavior as briefly
tested with several host platforms and file systems.
The first part of the chapter reviews the AIX Logical Volume Manager (LVM) concepts and our
observations with extent space-efficient (ESE) volumes in that environment.
The second part of this chapter describes the migration from standard to ESE volumes in a
Microsoft Windows environment. This part presents tools and methods that can be used in
that context. This part is divided into the following sections:
Migration considerations
Methods and tools for migration
Examples of migrating to ESE volumes
This chapter also presents general performance comparisons between ESE volumes and
standard volumes.
81
7.1 ESE volumes in IBM AIX with JFS2

This section describes our observations of thin-provisioned volumes when used with the AIX
JFS2. The section starts with a brief review of the AIX Enhanced Journaled File System
(JFS2) concepts and terminology.
Note: The logical volumes on the DS8000 are the Physical Volumes as seen by AIX (and
therefore different from the Logical Volumes used by AIX). The term volume group has two
meanings as well, depending on the context.
In this section, the entities in lowercase represent the DS8000 view (that is, logical volume
and volume group). The entities in uppercase represent the AIX terminology (that is,
Physical Volume, Logical Volume, File System, and Volume Group).
7.1.1 Introduction to AIX JFS2 concepts and terminology

The IBM AIX operating system includes a Logical Volume Manager (LVM). LVM allows the
creation of a Volume Group. Each Volume Group is configured with one or more Physical
Volumes. The Physical Volumes are divided into one or more Physical Partitions for which you
can specify a size at the Volume Group creation. The Physical Partitions are allocated to
Logical Partitions of a Logical Volume. Each Logical Partition has at least one Physical
Partition allocated, but there can be two additional Physical Partitions allocated to provide
mirrored copies for that Logical Volume. For more information about AIX LVM, see the
following web page:
http://ibm.co/1pjr6Sg
The available sizes of the Logical Partitions and Physical Partitions are limited to an integral
number of binary megabytes (MiB) so that the integer is a power of 2. The number of Physical
Partitions in a Volume Group depends on the Volume Group type, which can be normal, big,
or scalable. For example, a big Volume Group has a limit of 128 x 1016 Physical Partitions.
The number of Logical Volumes is limited to 512; the number of Physical Volumes is limited to
128; and the number of Physical Partitions on a Physical Volume is limited to 1016, by default.
Flexibility exists because the number of Physical Partitions per Physical Volume can be
increased by a factor of N if, at the same time, the number of Physical Volumes is reduced by
a factor of N (so that the maximum number of Physical Partitions 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 kernels.
The File System is created in a Volume Group and uses two Logical Volumes, by default: one
for the Journal Log File and one for the File System data. Typically, the Journal Log File
Logical Volume is configured with a single Logical Partition. The File System data Logical
Volume uses the remaining one or more Logical Partitions. (There is another option to create
the JFS2 File System in an existing Logical Volume, but this option is not described in detail in
this paper). The Journal Log File can also be configured to be placed inline within the File
System Logical Volume.
Multiple File Systems can share a common Log File, or a pair of common Log Files, which
can be resized as the File System size grows. The File System can be 16 MB - 32 TB in size
with a maximum file size of 16 TB. The File System Logical Volume can also be resized by the
user, as needed. The File System can be defined to use either a 512 byte, 1 KB, 2 KB, or
4 KB byte block size to allocate space. The default size is 4k bytes.
82
There are similar trade-offs for the space-efficient implementation considerations. A larger
block size reduces fragmentation, allocation frequency, and allocation map structures
(metadata overhead). A smaller block size might waste less space.
The JFS2 divides the File System space into up to 128 equally sized allocation groups that
have a minimum size of 32 MB (only the last allocation group might not be full-size). The File
System distributes data across the allocation groups under certain situations to improve the
localization of data that 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.
Terminology overlaps between AIX and DS8000

Similar terms are used by the DS8000 and AIX to describe different objects or concepts.
DS8000 terminology
The DS8000 configures physical disk drives into arrays and ranks. Ranks are added into
extent pools, which contain the extents of all ranks. The extents in an extent pool are used to
create logical volumes. The DS8000 logical volumes are presented and made accessible to
open system host bus adapters (HBAs) by grouping them into a volume group.
AIX terminology
AIX configures Physical Volumes into Volume Groups. Volume Groups contain Physical
Partitions that are allocated to Logical Partitions on Logical Volumes. The Logical Volumes
are used by applications, such as File Systems and Databases.
7.1.2 Test results on AIX with JFS2 File System

In the tests performed with the AIX JFS2 file system and thin provisioning, the file system
created metadata in up to three places on the ESE volume. Depending on the Partition Sizes
and Logical Volume structures that are used, the file system allocates 1- 3 extents per
DS8000 logical volume, resulting in an initial allocation of up to three 1 GB real extents for that
logical volume. Using a 100 GB file system, this is only a 3% initial allocation, but for a 10 GB
file system, it is already a 30% initial allocation.
These tests also revealed that the JFS2 reuses space well. After deleting data from the file
system, the previously allocated space is not released, but the space is reused to store new
data that is written to the volume. A new extent is allocated to the ESE volume only if the new
data to be written is larger than the unused, previously allocated space.
Based on the behavior that was shown, we expect that JFS2 on AIX and any application that
is using this file system will behave well regarding data placement and efficiency for use with
DS8000 thin provisioning.
When you create a mirrored Logical Volume, we advise you to set it up that way initially,
creating the second or third copy directly at the creation of the Logical Volume. Adding copies
to an existing Logical Volume results in full allocation of the Physical Volumes (therefore full
extent allocation to the DS8000 ESE logical volume) added when LVM synchronizes the new
copies.
For the test results and additional details, see the IBM white paper by Rick Ripberger and Yan
Xu, IBM DS8000 Storage Allocation Overview including Thin Provisioning, which is available
at the following web page:
http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101550
Chapter 7. Host considerations and migration to ESE volumes
83
Figure 7-1 shows that the storage %allocation closely tracks the File System % usage for
monotonically increasing data.
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 7-1 AIX with JFS2 File System: 128 KB Files - Fill 0 - 100%
Figure 7-2 shows the %Usage information for the file system and the %Alloc information for
the thin-provisioned logical volume while 128 KB files were copied into a single directory of
the file system. In this case, however, the file system was filled to about 50% full, then 25% of
the data was deleted, then filled to 75% full, then 25% of the data was deleted, and finally
filled to 100% full. As shown, after space is allocated on the logical volume, the deletion of
data from the file system does not release any of the previously allocated data. It is important
to note that while the file system is again filled with data up to the level that matches the
storage allocation after each deletion, no additional space was allocated. Therefore, the file
system reused the previously allocated space on the volume to store new data before
accessing unallocated space.
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-2 AIX with JFS2 File System: 128 KB Files - 0 - 100% with 25% deletions
84
7.2 Migration considerations

Enabling thin provisioning on the DS8000, as described in Chapter 4, Enabling thin
provisioning on page 35, does not mean that existing volumes will immediately or
automatically be transformed into thin-provisioned (ESE) volumes. It also does not mean that
you will automatically benefit from thin provisioning.
To take advantage of thin provisioning, you need to migrate data on existing standard
volumes to thin-provisioned volumes. You will therefore first need to configure new extent
space-efficient (ESE) volumes and use them as additional, new volumes or migrate your
existing standard volumes onto the ESE volumes.
You must also ensure that the host operating systems and applications that you intend to use
with the ESE volumes behave in a way so that they can take advantage of thin provisioning.
You need to understand how the OS or application allocates space for data. Ideally, to benefit
from thin provisioning, space allocation needs to use contiguous blocks, and applications
need to be able to reclaim deleted and unused blocks of storage. However, this is not
necessarily the case in practice. Certain applications always consume new space before
reusing already written but available space. These applications are not good candidates for
thin provisioning.
Space allocation theory: Host view versus storage system view

There is often confusion about how space allocation occurs. The confusion is about from
which standpoint is the allocation considered: the host standpoint or the storage system
standpoint.
In general, volumes have a file system installed on them, and how full the file system might be
is not the same as how full the volume is. Assuming that the file system is configured to have
access to the complete volume, the volume will always be at least as full as the file system.
From a storage system perspective, the percentage of a volume used will always increase
and never decrease.
Figure 7-3 on page 86 shows why an individual volumes usage never decreases. The figure
shows a theoretical case of how a file system and a volume are used as files and are written
and deleted from the file system.
Steps 1 and 2 in Figure 7-3 on page 86 show that the file system and the volume both report
the same percentage used while files are written to the file system.
Step 3 in Figure 7-3 on page 86 shows where a difference occurs between what the host or
file system reports and what the storage reports. In this step, files 1 and 2 are deleted;
therefore, the blocks used by these files are available to the file system. The only file still
visible in the file system is file 3. So, the file system reports that it is 25% full. However, the
storage is still reporting that it is 75% full. The storage shows 75% full because the storage
does not know that the data written for files 1 and 2 is no longer needed. The space in the
graphic is shaded because, from the storage perspective, those blocks still contain valid data.
When a file is deleted, the file system does not send any type of erase or delete command to
the storage array. It simply changes a pointer in its tables that pointed to the file and makes
those blocks available for future use. Because the blocks that contain the files are not actually
erased, undelete utilities are able to recover files after the user has deleted them.
85
Figure 7-3 Volume capacity: Host view versus storage view
In Step 4 of Figure 7-3, file 4 is shown as written to the last 25% of the volume. This step
depicts how a file system does not necessarily attempt to keep data at the beginning of a
volume. This is also shown in Figure 7-4, which shows the layout of a NTFS file system that is
75% full. After Step 4 in Figure 7-3, every block in the volume has been written and is,
therefore, full from a storage perspective. The fill percentage of a volume will never go down
(as shown in Step 5 - Step 7). Regardless of the host activity on the volume, the fill
percentage of the volume will remain 100% full.
Figure 7-4 Volume usage
86
Migration issues
The problem with migrating to extent space-efficient (ESE) volumes is that the traditional
logical volume managers will copy every block from the original standard volumes and write it
to the new ESE volumes. As a result, the ESE volumes fill up. All empty blocks will also be
copied to the ESE volumes and that physical capacity must be allocated for the entire ESE
volume. This type of migration defeats the purpose of thin provisioning as illustrated in
Figure 7-5.
Figure 7-5 Traditional copy
The solution to this problem is to move up to a host-based level software that knows whether
a block is occupied or not. This will make the copy more efficient and effectively use
thin-provisioned volumes. One possible solution is IBM Data Mobility Services Softek TDMF
(IP) for Windows software with the Thin Copy feature. This feature enables migrations from
traditional storage to thinly provisioned storage in Windows environments, copying only
allocated space and reclaiming any free space on the IBM System Storage DS8000
(Figure 7-6).
Figure 7-6 Thin Copy feature
87
7.2.1 Thin provisioning usage cases

The following use cases are considered when using thin provisioning:
Migrate from standard to empty or non-empty ESE volumes
Copy ESE to ESE volume
Defragment and release unused space on the ESE volume
7.2.2 Migration tools and utilities

Migration to ESE volumes can be similar to traditional migration of data from one type of
storage to another type. To make it more efficient and not to defeat thin provisioning, only
copy used blocks the original standard volumes to the new ESE volumes.
The following tools and utilities can be used to migrate your data to ESE volumes efficiently:
Standard OS copy command
Volume manager (AIX LVM or Veritas Storage Foundation - Smart Move)
Software tools (IBM Softek TDMF (IP) for Windows using the Thin Copy feature)
7.3 Examples of migrating to ESE volumes on Windows

This section describes different test scenarios that illustrate migrating to ESE volumes in
Windows environments with IBM Softek TDMF (IP) for Windows using the Thin Copy feature.
The intent of the testing with the TDMF Thin Copy feature is to show how TDMF can be used
to perform a data migration from standard volumes to the new ESE volumes. The preferred
practices are documented along with tips when migrating to ESE volumes.
7.3.1 Softek TDMF product

IBM Softek TDMF is host-based software that runs on both open systems and System z
Series platforms. It migrates data nondisruptively while applications are still online for
business use. The data is moved on a per volume basis quickly because the data is moved at
the block level. TDMF can be used for both local storage subsystems replacement, remote
migrations for data center relocation, or storage and server consolidation. The supported
operating system platforms include Microsoft Windows, AIX, HP-UX, Solaris, Linux, and
IBM z/OS. See the following web page for additional information about TDMF products:
http://www.ibm.com/services/us/index.wss/offerfamily/gts/a1028233
The TDMF software can be used to migrate to the new thin-provisioned volumes that exist on
the IBM System Storage DS8000. Specifically, the TDMF (IP) for Windows Thin Copy feature
allows only the data blocks that are in use on an NTFS file system to be moved from a
traditional fat logical unit number (LUN) to a new thin (ESE) LUN on the IBM System
Storage DS8000. This copy function is a significant performance improvement and a valuable
function for any thin-provisioned storage device, such as the IBM System Storage DS8000. It
migrates data in the background while maintaining application availability.
Without this type of functionality, it is difficult to migrate existing data to a thin-provisioned
device because a normal copy defeats the purpose of the thin-provisioned device by causing
the IBM System Storage DS8000 to fully back the virtual disk container with physical disk
resources.
88
The Thin Copy feature reads the NTFS allocation map and copies only the data blocks that
are in use by the NTFS file system (Figure 7-6 on page 87). While the data is copied, the
application is fully available. Any updates that occur during the copy phase are mirrored to the
target device while the updates on the application server occur. This method ensures that the
source and target disk are complete synchronized at the end of the migration.
TDMF (IP) for Windows copies data at the partition level so that it can copy drive letters or
mount points. This allows the LUN structure to be reorganized in conformance with the
particular storage device. For example, a dynamic volume that consists of five LUNs can be
reformed into a dynamic volume that consists of a single LUN that was defined as an ESE
volume on the IBM System Storage DS8000.
Because TDMF works at the volume level and is a block-based copy, it is easy to select only
the source and target drive letter to perform the copy. There is no chance of missing any files.
By default, all files, whether they are open or not, will be copied from the source volume to the
target volume. There is no chance for any change in the file permissions that might cause
application problems or corruption.
7.3.2 Typical scenarios

This section shows cases that were tested using various volume sizes and different
percentages of file system usage within the NTFS file system. It also describes scenarios that
you might consider:
Windows Quick Format allocation
Migration from standard volume to ESE volume
Migration from smaller standard volume to bigger ESE volume and extension of the NTFS
file system on Windows
Copy ESE to ESE
Defragment and release unused space on the ESE volume
The test environment consists of the following products:
Windows Server 2008 SP2
IBM Softek Data Mobility Console 1.1.1
Windows Server 2003 R2 EE SP2
IBM Softek TDMF (IP) for Windows 3.1.0
IBM System Storage DS8300 R4.3
Windows Quick Format allocation

Four standard volumes and four extent space-efficient volumes of different capacities (10 GB,
25 GB, 50 GB, and 100 GB) were attached to the Windows test server.
89
We used Windows Quick Format on the ESE volumes, which resulted in the extent allocation
that is shown in Table 7-1.
Table 7-1 ESE real capacity after Quick Format
ESE volume capacity
Real (DS8000) extents used
10 GB
25 GB
50 GB
100 GB
Remember: One extent is 1024 MB or 1 GB.

Normal formatting does not cause any additional extents to be allocated above the extents
that are shown in Table 7-1. It deletes old files and checks for bad blocks but does not cause
any backing of the real storage from the storage pool.
7.3.3 Migration from standard volumes to ESE volumes

After the volumes were formatted, we tested migration to the empty ESE volumes. The tests
included volumes of different capacities (10 GB, 25 GB, 50 GB, and 100 GB) and different
space allocation percentages in the file system (25%, 50%, 75%, and 100%). We migrated by
using the Softek Data Mobility Console (DMC), which is the management console for IBM
Softek TDMF (IP) for Windows.
Important: IBM Softek TDMF (IP) for Windows with the Thin Copy feature supports the
migration of standard volumes to ESE volumes on the local server only. Therefore, you
must attach the old storage and the new storage to the same server.
Note: In a typical migration environment, one downtime is required to install Softek TDMF
(IP) for Windows. If the migration is planned carefully, only a single reboot is necessary
during this process. This reboot is normally required to set up Softek TDMF (IP) for
Windows and also to install the virtual device driver in the kernel. A second downtime
might be required to switch over to new devices and remove Softek TDMF (IP) for Windows
from the system. To migrate in a single downtime, careful planning is required. Drive letters
must be reassigned and, if drive letters are changed, shares must also be re-created.
Figure 7-7 on page 91 shows the IBM Softek Data Mobility Console main window and the
server information and properties used for the tests.
90
Figure 7-7 IBM Softek Data Mobility Console (DMC) main window
For details about the IBM Softek Data Mobility Console, see the publication IBM Data Mobility
Services Softek Data Mobility Console Installation and User Guide, DMC-W11IU-003.
The following steps show how we migrated the standard volumes to ESE volumes:
1. In the DMC, we created mobility groups that include standard volumes and ESE volumes
on the test server. Figure 7-8 shows the mobility group properties.
Figure 7-8 Mobility group properties
91
2. When you create the mobility group, you must enable the Thin Copy feature by selecting
the corresponding check box. The target server must also be the same as the primary
server, because the Softek TDMF (IP) for Windows Thin Copy feature is only supported on
the same local server.
3. Under the Volume Pairs tab, you must add the volumes to migrate. Figure 7-9 shows the
volume pair that we added for our scenario.
Figure 7-9 Volume pair
After the mobility group is created, you can start the migration.
4. From the DMC main window, select the group and right-click it. A menu displays where
you click Commands (Primary) and then click Start. You must confirm that you want to
start the migration process (Figure 7-10). Click Yes.
Figure 7-10 Start the mobility group
5. By starting the mobility group, you start the driver that provides TDMF with the ability to
track and mirror changes to the source volume. To start the migration, you must issue
Launch Refresh (Full) against the group, as shown in Figure 7-11 on page 93.
92
Figure 7-11 Start migration
6. You can check the migration progress by selecting the mobility group, as illustrated in
Figure 7-12.
Figure 7-12 Mobility group migration
7. After the migration completes, the Mobility Group icon turns green and its mode is Normal
and its status is Connected (Figure 7-13 on page 94). You have successfully migrated
your standard volumes to ESE volumes.
93
Figure 7-13 Successful migration status
Migrating an empty standard volume to an ESE volume

In this test, we migrated an empty standard volume to a newly defined ESE volume. We
recorded the number of used real extents on the DS8000. The results shows that the number
of allocated extents (on the DS8000) did not change after the volume was migrated, as
depicted in Table 7-2.
Table 7-2 Empty standard volume to ESE volume migration
Standard
volume capacity
Standard
volume capacity
used
ESE volume
capacity
Real extents
used before
migration
Real extents
used after
migration
10 GB
0%
10 GB
25 GB
0%
25 GB
50 GB
0%
50 GB
100 GB
0%
100 GB
Migrating a non-empty standard volume to an ESE volume

With this test, we migrated non-empty standard volumes to ESE volumes. We used different
percentages of the file system usage within the NTFS file system and we recorded the
percentage of storage used on the DS8300. The results are shown in Table 7-3 on page 95.
Note: The file generator tool used in the tests to consume space on the standard volumes
was generating 1024 KB files in a specific folder, and it filled the files with random
characters.
94
Table 7-3 Non-empty standard volume to ESE volume

Standard volume
capacity
Standard volume
capacity used
ESE volume capacity
Real extents used

after migration
10 GB
25%
10 GB
25 GB
25%
25 GB
10
50 GB
25%
50 GB
16
100 GB
25%
100 GB
30
10 GB
50%
10 GB
25 GB
50%
25 GB
15
50 GB
50%
50 GB
28
100 GB
50%
100 GB
53
10 GB
75%
10 GB
10
25 GB
75%
25 GB
21
50 GB
75%
50 GB
40
100 GB
75%
100 GB
78
The results show that you can benefit more from thin provisioning when you use larger
volumes because the ratio of allocated real extents is higher with smaller volumes.
Migrating from a standard volume to a non-empty ESE volume

When you migrate to a non-empty ESE volume, you must release all the space on the ESE
volume.
Example 7-1 shows how to use the DS CLI initfbvol command to release the space (on the
DS8000). It shows the status before and after you release the space.
This action deletes old data on the ESE volume.
Example 7-1 Release the space for an ESE volume
dscli> showfbvol 4910

IBM.2107-7520781
Name
itsotdmf10ese
ID
4910
accstate
Online
datastate
Normal
configstate
Normal
deviceMTM
2107-900
datatype
FB 512
addrgrp
4
extpool
P5
exts
10
captype
DS
cap (2^30B)
10.0
cap (10^9B)
cap (blocks)
20971520
volgrp
V12
95
ranks
dbexts
sam
repcapalloc
eam
reqcap (blocks)
realextents
virtualextents
1
0
ESE
rotatevols
20971520
5
10
dscli> initfbvol 4910

IBM.2107-7520781
CMUC00337W initfbvol: Are you sure that you want to submit the command
releasespace for the FB volume 4910?[Y/N]:y
CMUC00340I initfbvol: 4910: The command releasespace has completed successfully.
IBM.2107-7520781
Name
itsotdmf10ese
ID
4910
accstate
Online
datastate
Normal
configstate
Normal
deviceMTM
2107-900
datatype
FB 512
addrgrp
4
extpool
P5
exts
10
captype
DS
cap (2^30B)
10.0
cap (10^9B)
cap (blocks)
20971520
volgrp
V12
ranks
0
dbexts
0
sam
ESE
repcapalloc
eam
rotatevols
reqcap (blocks) 20971520
realextents
0
virtualextents 10
Migrating from a smaller standard volume to a larger ESE volume

In this test, we migrate from a standard volume to a larger ESE volume. We migrate the data
by using Softek TDMF (IP) for Windows.
The source standard volume (volume id 4811 - Q:) has a capacity of 25 GB and is 75% used.
The target ESE volume (volume id 4913 - P:) is configured as a 100 GB capacity volume and
is initially empty (Figure 7-14 on page 97). Although it is initially empty, the ESE volume
consumes six real extents. Example 7-2 on page 97 shows the volume status on the DS8000
before the migration.
96
Figure 7-14 Source standard volume and target ESE volume before the migration
Example 7-2 Volume status before the migration

Date/Time: 2009. kolovoz 24 17:20:25 PDT IBM DSCLI Version: 5.4.30.244 DS:
IBM.2107-7520781
Name
itsotdmf25std
ID
4811
accstate
Online
datastate
Normal
configstate
Normal
deviceMTM
2107-900
datatype
FB 512
addrgrp
4
extpool
P4
exts
25
captype
DS
cap (2^30B)
25.0
cap (10^9B)
cap (blocks)
52428800
volgrp
V12
ranks
1
dbexts
0
sam
Standard
repcapalloc
eam
rotatevols
realextents
25
virtualextents 0
97
IBM.2107-7520781
Name
itsotdmf100ese
ID
4913
accstate
Online
datastate
Normal
configstate
Normal
deviceMTM
2107-900
datatype
FB 512
addrgrp
4
extpool
P5
exts
100
captype
DS
cap (2^30B)
100.0
cap (10^9B)
cap (blocks)
209715200
volgrp
V12
ranks
1
dbexts
0
sam
ESE
repcapalloc
eam
rotatevols
realextents
6
virtualextents 100
Figure 7-15 shows the migration status in the IBM Softek Data Mobility Console window.
Figure 7-15 Migration status in the DMC window
98
Figure 7-16 shows the volumes in Windows Explorer while the migration is underway.
Information for the target volume is not displayed because the volume is inaccessible during
the migration.
Figure 7-16 Source volume and target volume in Windows Explorer during the migration
When the migration is finished (Figure 7-17), you can stop the mobility group (Figure 7-18 on
page 100).
Figure 7-17 Status of the finished migration
99
Figure 7-18 Stopping the mobility group
By stopping the mobility group, the target volume becomes available (Figure 7-19). However,
it shows that the size of the volume is 25 GB. Windows does not automatically expand the
volume. It must be expanded manually.
Figure 7-19 Source volume and target volume in Windows Explorer after the migration
100
Example 7-3 shows the target ESE volume information from the DS CLI. You can see that 23
real extents are used.
Example 7-3 Target ESE volume information

IBM.2107-7520781
Name
itsotdmf100ese
ID
4913
accstate
Online
datastate
Normal
configstate
Normal
deviceMTM
2107-900
datatype
FB 512
addrgrp
4
extpool
P5
exts
100
captype
DS
cap (2^30B)
100.0
cap (10^9B)
cap (blocks)
209715200
volgrp
V12
ranks
1
dbexts
0
sam
ESE
repcapalloc
eam
rotatevols
realextents
23
virtualextents 100
dscli>
Using Softek TDMF (IP) for Windows, you can expand the volume. In the IBM Softek Data
Mobility Console window, select the mobility group that corresponds to the migrated volumes.
Click the Command tab and select the util command. Enter the parameter -x and click Go.
101
Figure 7-20 shows that the command completed successfully.
Figure 7-20 Expanding the target ESE volume
Windows Explorer in Figure 7-21 also shows the correct capacity now.
Figure 7-21 Source volume and target volume in Windows Explorer after the expansion
102
Copying an ESE volume to an ESE volume

To copy an ESE volume to another ESE volume, use the following steps:
1. Quiesce applications on the source ESE volume.
2. Release all space on the target ESE volume.
3. Copy only files from the source to the target using a compatible File System or Softek
TDMF (IP) for Windows.
4. Resume applications.
Defragmenting and releasing unused space on an ESE volume

To defragment and release unused space on an ESE volume, use the following steps:
1. Quiesce applications.
2. Copy files to a temporary volume.
3. Release all space on the ESE volume.
4. Copy files back to the ESE volume by using a compatible File System or Softek TDMF (IP)
for Windows.
5. Resume applications.
7.3.4 Conclusion
When you migrate existing data to thinly provisioned storage, such as DS8000 ESE volumes,
the host layer is the only layer in the I/O path that has the intelligence to move only the
relevant data. Softek TDMF (IP) for Windows is host-based and moves only the data in the
NTFS file system that is still active. This approach allows an enterprise to deploy a
thin-provisioned device and realize storage savings because any free space in the file system
is returned back to the available storage pool within the DS8000.
Based on the test migrations that we performed moving Windows NTFS file systems from
standard volumes to ESE volumes by using Softek TDMF (IP) for Windows Thin Copy for
data, we can formulate the following observations and suggestions:
Good candidates for ESE volumes include large file systems with low utilization rates and
file systems with large contiguous areas of free storage within the file systems. To identify
these good candidates, use the normal drive utilization reports and the defragmentation
reports to find file systems with contiguous free storage. Note that the contiguous space is
marked by blocks of white in the Windows defragmentation reports. Figure 7-22 on
page 104 shows a defrag report for a volume with a large contiguous area, illustrating a
good candidate.
Typically, it is not advantageous to run Windows defragmentation on source volumes
before a migration using the TDMF Thin Copy option. The method that the NTFS file
system uses to allocate storage favors the reuse of space so often there is large
contiguous storage available in underutilized file systems. Consequently, a
defragmentation of the file system does not cause any substantial disk space savings
when you migrate it to an ESE volume. There might be special cases where a disk
defragmentation can help slightly but they were not observed in our tests. It is not advised
to run disk defragmentation on DS8000 ESE volumes.
103
Figure 7-22 Defragmentation report
7.4 Thin provisioning software

IBM JFS2 File System on AIX has had some evaluation by IBM and is thought to be well
behaved for DS8000 thin provisioning.
The following additional software has had less evaluation, but is thought 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 (IP) for Windows Thin Data Copy Option
The following software has had less evaluation, but is thought to have the described
characteristics that are not ideal for DS8000 thin provisioning:
Oracle OCFS2 on Linux
Grows space allocation faster than file system usage
Ext 2 on Linux
Large initial storage allocation when creating the file system
The following software has had less evaluation, but without any special customization that
might be available, is thought to have characteristics that do not make these products suitable
for thin provisioning with the DS800:
104
IBM General Parallel File System (GPFS) on AIX and on Linux

HP-UX Hierarchical File System (HFS)
Solaris UNIX File System (UFS)
SGI XFS
Episode Distributed File System (DFS)
Ext3 on Linux
Related publications
The publications listed in this section are considered particularly suitable for a more detailed
discussion of the topics covered in this paper.
IBM Redbooks
For information about ordering these publications, see How to get Redbooks publications on
page 105. Note that some of the documents referenced here might be available in softcopy
only.
IBM DS8870 Architecture and Implementation, SG24-8085
IBM System Storage DS8000 Series: IBM FlashCopy SE, REDP-4368
Other publications
These publications are also relevant as further information sources:
IBM DS8000 Storage Allocation Overview including Thin Provisioning:
http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101550
IBM DS8000 Series Command-Line Interface Users Guide, GC27-4212-02
IBM DS8870 Introduction and Planning Guide, GC27-4209
Online resources
The following websites also are relevant as further information sources:
IBM data storage feature activation (DSFA) website
http://www.ibm.com/storage/dsfa
Documentation for the DS8000: The Information Center
http://publib.boulder.ibm.com/infocenter/dsichelp/ds8000ic/index.jsp
System Storage Interoperation Center (SSIC)
http://www.ibm.com/systems/support/storage/config/ssic
How to get Redbooks publications

You can search for, view, or download Redbooks, Redpapers, Technotes, draft publications
and Additional materials, as well as order hardcopy Redbooks publications, at this website:
ibm.com/redbooks
105
Help from IBM

IBM Support and downloads
ibm.com/support
IBM Global Services
ibm.com/services
106
Back cover

Redpaper
Avoid allocating
unused capacity
Read about new ESE
repository
capability and new
controls
Understand
applications and
OS implications
Ever-increasing storage demands have a negative impact on an

organizations IT budget and complicate the overall storage
infrastructure and management. Companies are looking at ways to use
their storage resources more efficiently.
Thin provisioning can help by reducing the amount of unused storage
typically allocated to applications or users. Thin provisioning, now
available for the IBM DS8000, defers the allocation of actual space on
the storage system until the time that the data must effectively be
written to disk.
This IBM Redpaper publication provides an overall understanding of
how thin provisioning works on the DS8000. It provides insights into
the functional design and its implementation on the DS8000 and
contains illustrations for the configuration of thin-provisioned volumes
from either the DS GUI or the DS CLI.
This edition reflects the capability to define an extent space-efficient
(ESE) repository, which was introduced with the DS8870 Release 7.2
firmware.
This paper also includes considerations that will help you decide which
applications will effectively benefit from thin provisioning. It takes you
through scenarios and utilities for migrating from standard volumes to
thin-provisioned volumes.
INTERNATIONAL
TECHNICAL
SUPPORT
ORGANIZATION
BUILDING TECHNICAL
INFORMATION BASED ON
PRACTICAL EXPERIENCE
IBM Redbooks are developed
by the IBM International
Technical Support
Organization. Experts from
IBM, Customers and Partners
from around the world create
timely technical information
based on realistic scenarios.
Specific recommendations
are provided to help you
implement IT solutions more
effectively in your
environment.
For more information:

ibm.com/redbooks
REDP-4554-01

Ds8000 Ese Pool

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ds8000 Ese Pool

Uploaded by

Copyright:

Available Formats

Front cover

DS8000 Thin Provisioning

Avoid allocating unused capacity

Read about new ESE repository

International Technical Support Organization

Second Edition (July 2014)

Copyright International Business Machines Corporation 2014.

Chapter 2. Planning considerations and guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Chapter 4. Enabling thin provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Copyright IBM Corp. 2014. All rights reserved.

Chapter 6. Managing and monitoring thin-provisioned volumes . . . . . . . . . . . . . . . . .

Chapter 7. Host considerations and migration to ESE volumes . . . . . . . . . . . . . . . . . 81

DS8000 Thin Provisioning

Copyright IBM Corp. 2014. All rights reserved.

The following terms are trademarks of other companies:

DS8000 Thin Provisioning

Copyright IBM Corp. 2014. All rights reserved.

Now you can become a published author, too!

Stay connected to IBM Redbooks publications

DS8000 Thin Provisioning

DS8000 Thin Provisioning

July 2014, Second Edition

New or changed information

Copyright IBM Corp. 2014. All rights reserved.

DS8000 Thin Provisioning

Copyright IBM Corp. 2014. All rights reserved.

1.1 General description

A volume supporting thin provisioning is referred to as a space-efficient volume. At the time

DS8000 Thin Provisioning

1.1.1 Thin provisioning model

Real capacity pool

Figure 1-2 Common model of DS8000 thin provisioning

Virtual capacity pool

Real capacity pool

Chapter 1. Thin provisioning

1.1.2 Thin provisioning usage examples

Thin provisioning for user data

Thin provisioning in data centers

DS8000 Thin Provisioning

1.2 DS8000-specific implementations

1.2.1 Track space-efficient (TSE) volumes

1.2.2 Extent space-efficient (ESE) volumes

Chapter 1. Thin provisioning

DS8000 Thin Provisioning

Planning considerations and

Copyright IBM Corp. 2014. All rights reserved.

2.1 General considerations

2.1.1 Thin provisioning benefits

Characteristics of the applications using the space-efficient volumes

In general, there is a trade-off between performance and space-efficiency, which depends on

DS8000 Thin Provisioning

Chapter 2. Planning considerations and guidelines

A generic recommendation about sustainable over-provisioning ratios is difficult to give,

DS8000 Thin Provisioning

The following options are available to release allocated extents

Chapter 2. Planning considerations and guidelines

Up to 4 PB total capacity (real and virtual) per storage facility image

DS8000 Thin Provisioning

2.2 Planning steps

2.2.1 Planning examples

Chapter 2. Planning considerations and guidelines

Examples including thin provisioning and FlashCopy SE

Input: Virtual TSE

DS8000 Thin Provisioning