ds8000 ese pool

ibm.com/redbooks Redpaper

Front cover

DS8000 Thin Provisioning

Bert DufrasnePeter KimmelBruce Wilson

Avoid allocating unused capacity

Read about new ESE repositorycapability and new controls

Understand applications and OS implications

http://www.redbooks.ibm.com/


International Technical Support Organization


July 2014

REDP-4554-01

© Copyright International Business Machines Corporation 2014. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP ScheduleContract with IBM Corp.

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.

Note: Before using this information and the product it supports, read the information in “Notices” on page v.

Contents

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .vTrademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiAuthors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiNow you can become a published author, too! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiiComments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiiStay connected to IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiJune 2014, Second Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Chapter 1. Thin provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 General description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.1 Thin provisioning model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.1.2 Thin provisioning usage examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 DS8000-specific implementations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.1 Track space-efficient (TSE) volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2.2 Extent space-efficient (ESE) volumes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Chapter 2. Planning considerations and guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1 General considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1 Thin provisioning benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.2 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.3 Sizing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.1.4 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.1.5 Applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Planning steps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.1 Planning examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Chapter 3. Space-efficient volumes in the DS8000 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.1 DS8000 logical volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2 Track space-efficient volumes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2.1 Repository for track space-efficient logical volumes . . . . . . . . . . . . . . . . . . . . . . . 193.3 ESE logical volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3.1 Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3.2 Optional ESE repository for ESE logical volumes. . . . . . . . . . . . . . . . . . . . . . . . . 213.3.3 Capacity allocation for ESE volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.3.4 Out-of-space condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.3.5 Volume creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3.6 Releasing space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.3.7 Migration considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.3.8 Performance considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Chapter 4. Enabling thin provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.1 Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.2 Activation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.3 Enabling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

© Copyright IBM Corp. 2014. All rights reserved. iii

4.4 Disabling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Chapter 5. DS GUI and DS CLI support for thin provisioning . . . . . . . . . . . . . . . . . . . . 415.1 DS GUI and DS CLI support for thin provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.2 DS Storage Manager GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.3 DS CLI commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.4 Logical configuration process for ESE volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.4.1 Configuring ESE volumes with the DS GUI illustrated . . . . . . . . . . . . . . . . . . . . . 585.4.2 Configuring ESE volumes with the DS CLI illustrated. . . . . . . . . . . . . . . . . . . . . . 66

Chapter 6. Managing and monitoring thin-provisioned volumes . . . . . . . . . . . . . . . . . 756.1 Management and monitoring capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6.1.1 Options to reserve space and buffer capacity. . . . . . . . . . . . . . . . . . . . . . . . . . . . 766.1.2 Options to set thresholds and receive warnings . . . . . . . . . . . . . . . . . . . . . . . . . . 766.1.3 SNMP trap: Extent pool threshold. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786.1.4 Managing out-of-space situations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Chapter 7. Host considerations and migration to ESE volumes . . . . . . . . . . . . . . . . . 817.1 ESE volumes in IBM AIX with JFS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

7.1.1 Introduction to AIX JFS2 concepts and terminology . . . . . . . . . . . . . . . . . . . . . . . 827.1.2 Test results on AIX with JFS2 File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

7.2 Migration considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857.2.1 Thin provisioning usage cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887.2.2 Migration tools and utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

7.3 Examples of migrating to ESE volumes on Windows . . . . . . . . . . . . . . . . . . . . . . . . . . 887.3.1 Softek TDMF product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 887.3.2 Typical scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897.3.3 Migration from standard volumes to ESE volumes . . . . . . . . . . . . . . . . . . . . . . . . 907.3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

7.4 Thin provisioning software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Other publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105How to get Redbooks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

iv DS8000 Thin Provisioning

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.

© Copyright IBM Corp. 2014. All rights reserved. v

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 DS8000 Thin Provisioning

http://www.ibm.com/legal/copytrade.shtml

Preface

Ever-increasing storage demands have a negative impact on an organization’s 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 Master’s 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.

© Copyright IBM Corp. 2014. All rights reserved. vii

For their input and advice during the preparation of this paper:

Rick Ripberger, Dale H. AndersonIBM US

Now you can become a published author, too!

Here’s an opportunity to spotlight your skills, grow your career, and become a published author—all 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:

[email protected]

� Mail your comments to:

IBM Corporation, International Technical Support OrganizationDept. HYTD Mail Station P0992455 South RoadPoughkeepsie, 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 DS8000 Thin Provisioning

http://www.ibm.com/redbooks/residencies.html

http://www.ibm.com/redbooks

http://www.redbooks.ibm.com/contacts.html

http://www.facebook.com/IBMRedbooks

http://twitter.com/ibmredbooks

http://www.linkedin.com/groups?home=&gid=2130806

� 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

https://www.redbooks.ibm.com/Redbooks.nsf/subscribe?OpenForm

http://www.redbooks.ibm.com/rss.html

x DS8000 Thin Provisioning

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 Changesfor DS8000 Thin Provisioningas 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.

© Copyright IBM Corp. 2014. All rights reserved. xi

xii DS8000 Thin Provisioning

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

© Copyright IBM Corp. 2014. All rights reserved. 1

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.

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.

CapacityPool

Real capacity Real capacityUsedcapacity

Virtual capacityUsedcapacity

Usedcapacity

Server Storage

Allocates onwrite

Full Provisioning

Thin Provisioning

2 DS8000 Thin Provisioning

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.

Figure 1-2 Common model of DS8000 thin provisioning

Virtual capacity poolThe 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 poolThe 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.

Virtual capacity pool

Real capacity pool

Write request comes to the space efficient volume

Capacity is allocated prior to the write

Volumes with user requested capacity are created from the virtual capacity pool

Chapter 1. Thin provisioning 3

Space-efficient volumesSpace-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 dataAs 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 centersIn 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 5

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.

2

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 capacityVirtual 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.

Over-provisioningOver-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.

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.

Chapter 2. Planning considerations and guidelines 9

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 poolsIn 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.


RAID levelsFrom 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 extentsThe 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.

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.

Important: For critical applications, standard logical volumes might be a better choice to avoid any risk of running into an out-of-space situation.


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.


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.

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.

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.


Examples including thin provisioning and FlashCopy SETo 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

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


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

-> number of drivesets needed for this real capacity:- 6+P arrays - 7+P arrays

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)

Example 1 Example 2


450 GB disks (6+P: 2430 GB)(7+P: 2835 GB)

-> 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:

Base frame max # drivesets:

8

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

Example 1 Example 2


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.

3


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 initializationAllocating 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.


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.

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.

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.

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.

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.

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.

Figure 3-1 illustrates the concept of TSE logical volumes.

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.

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.

ExtentPool

Ranks

Repository forspace efficientvolumesstriped acrossranks

normalVolume

Virtual repository capacity

Usedtracks

Allocated tracks

Spaceefficientvolume


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 capacityThe 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.


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.

ESE volumes without an ESE repositoryWhen 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.

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.


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 capacitySpace for ESE volume data ..... 1,000 GiB - your decision Allocated extent pool space ....... 0 GiB - assumes there is no TSE repository

or standard volumesSpace available for metadata .. 1,122 GiB

Approximate total virtual capacity for ESE volumes is 224,400 GiBThis 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.


Example 3-2 Using opratio

Available capacity (GUI) .... 481,694 GiB

Total extent pool capacity .... 2,122 GiB - actual physical capacitySpace for ESE volume data ..... 2,080 GiB - your decision Allocated extent pool space ....... 0 GiB - assumes there is no TSE repository

or standard volumesSpace used for metadata .......... 42 GiBOpratio ........................... 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 Opratio required 4:1Space for ESE volume data ..... 2,500 GiBSpace required for metadata ...... 50 GiB

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 pool’s virtual capacity.


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.

ESE volumes with an ESE repositoryThe 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.

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.


� 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.


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.


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:

� configuredGives the number of real extents that are configured to the extent pool.

� allowedThe 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.

� availableThe 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.

� allocatedThe 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.


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.

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.

Important: Out-of-space conditions in an extent pool need to be avoided in any case, because this definitely translates into application access loss.


Figure 3-4 illustrates these concepts of threshold and extent limit without an ESE repository.

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.

Extent Pool

Available Extents

Extent Threshold

Extent Limit

Free Extents

Used Extents forStandard LV

Restricted ExtentsVirtual Capacity

ESE LV

Used Extents forESE LV

Standard LV


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 volume’s 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.


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.


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.


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.

4

Note: The Thin Provisioning feature license applies only to extent space-efficient (ESE) volumes.


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.



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-7520781Date/Time: 2009. kolovoz 04 18:46:16 CEST IBM DSCLI Version: 5.4.30.210 DS: IBM.2107-7520781Activation Key Authorization Level (TB) Scope==========================================================================High Performance FICON for System z (zHPF) on CKDIBM FlashCopy SE 276 AllIBM HyperPAV on CKDIBM System Storage DS8000 Thin Provisioning on AllIBM database protection on FBMetro/Global mirror (MGM) 106,7 AllOperating environment (OEL) 105,6 AllParallel access volumes (PAV) 105,6 CKDPoint in time copy (PTC) 105,6 AllRemote mirror and copy (RMC) 105,6 AllRemote mirror for z/OS (RMZ) 105,6 CKDdscli>

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.

Example 4-2 New threshold value after enabling thin provisioning

dscli> showextpool P10Date/Time: 2009. august 04 21:16:40 CEST IBM DSCLI Version: 5.4.30.210 DS: IBM.2107-7520781Name gero_0ID P10stgtype fbtotlstor (2^30B) 452availstor (2^30B) 0resvdstor (2^30B) 0rankgrp 0numranks 1numvols 1status full%allocated 100%available 0configured 452allowed 452available 0allocated 452reserved 0%limit 100%threshold 15virextstatus full%virallocated 0%viravailable 0virconfigured 0virallowed 0viravailable 0virallocated 0virreserved 0%virextlimit -%virextthreshold -encryptgrp -%allocated(ese) 0%allocated(rep) 0%allocated(std) 100%allocated(over) 0%virallocated(ese) -%virallocated(tse) -%virallocated(init) -dscli>

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.


Effect on existing FlashCopy TSE target volumesTo 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

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.

5


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:

� 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 windowThe 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 windowThe 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.

Internal Storage window and Extent Pools tabThe 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.

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.


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.


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 poolsThe 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.

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 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)


The mksestg commandThe 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.

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 p6CMUC00342I 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.

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.

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.


� 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 commandThe 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 P5CMUC00343I 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.

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 commandThe 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.)

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.


Example 5-3 Report from the lssestg command

dscli> lssestg -lextpool 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.1P6 fb Normal Normal below 100.0 1000.0 tse 0.0 1000.0 10.0P8 fb Normal Normal below 100.0 2000.0 tse 0.0 1000.0 10.0P10 fb Normal Normal below 100.0 2000.0 tse 0.0 1000.0 10.0P10 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 User’s 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 User’s 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.


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.)

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).

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.


The showsestg commandThe 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 p10extpool P10stgtype fbdatastate Normalconfigstate Normalrepcapstatus below%repcapthreshold 0repcap(GiB) 125.6repcap(Mod1) -repcap(blocks) 263486176repcap(cyl) -repcapalloc(GiB/Mod1) 0.0%repcapalloc 0vircap(GiB) 2000.0vircap(Mod1) -vircap(blocks) 4194304000vircap(cyl) -vircapalloc(GiB/Mod1) 1000.0%vircapalloc 4overhead(GiB/Mod1) 9134.4reqrepcap(GiB/Mod1) 125.6reqvircap(GiB/Mod1) 210000.0reptype eseopratio 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.

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.


� %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 commandThe 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 4810CMUC00025I mkfbvol: FB volume 4810 successfully created.

The lsfbvol and showfbvol commandsThe 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 -lName 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.

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 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 000aName Testese0ID 000Aaccstate Onlinedatastate Normalconfigstate NormaldeviceMTM 2107-900datatype FB 512addrgrp 0extpool P16exts 100captype DScap (2^30B) 100.0cap (10^9B) -cap (blocks) 209715200volgrp V2ranks 1dbexts 0sam ESErepcapalloc -eam managedreqcap (blocks) 209715200realextents 22virtualextents 100....

See the command help report for an explanation of all the fields in this report.

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 commandThe 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.

Note: The repcapalloc field will be a dash (-) if the sam field is not tse.


� %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 P4Name fb_r5_0ID P4stgtype fbtotlstor (2^30B) 3104availstor (2^30B) 999resvdstor (2^30B) 0rankgrp 0numranks 8numvols 116status below%allocated 67%available 32configured 3104allowed 3104available 999allocated 2105reserved 0%limit 100%threshold 15virextstatus below%virallocated 8%viravailable 91virconfigured 12000virallowed 12000viravailable 11000virallocated 1000virreserved 0%virextlimit 100%virextthreshold 0encryptgrp -%allocated(ese) 14%allocated(rep) 11%allocated(std) 39%allocated(over) 1%virallocated(ese) 7%virallocated(tse) 0%virallocated(init) 0


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 commandThe 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.

Example 5-9 illustrates the use of the initfbvol command with the -action parameter.

Example 5-9 The initfbvol command

dscli> initfbvol -action releasespace 4611CMUC00337W initfbvol: Are you sure that you want to submit the command releasespace for the FB volume 4611?[Y/N]:yCMUC00340I initfbvol: 4611: The command releasespace has completed successfully.

Important: The initfbvol -action releasespace command deletes all data on the specified volume.


The lsvolinit commandThe 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.

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 user’s 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.

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.


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 volumesFollow 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.


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.

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.

Note: You can only select more than one extent pool if the pools are sequential.


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.


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.


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 GUIThe 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.


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

Internal Storage window and Extent Pools tabThe 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.)


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.


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 pageThe 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 GUIAn 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.

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

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.


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).

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 repositoryTo 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.

Note: The available capacity is indicated based on the available extents in the extent pool.


Example 5-10 Creating the ESE repository

dscli> mksestg -reptype ese -repcap 500 p16CMUC00342I 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 p16extpool 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

dscli> showsestg -reptype ese p16extpool P16stgtype fbdatastate Normalconfigstate Normalrepcapstatus below%repcapthreshold 0repcap(GiB) 509.0repcap(Mod1) -repcap(blocks) 1067534208repcap(cyl) -repcapalloc(GiB/Mod1) 0.0%repcapalloc 0vircap(GiB) 0.0vircap(Mod1) -vircap(blocks) 0vircap(cyl) -vircapalloc(GiB/Mod1) 0.0%vircapalloc 0overhead(GiB/Mod1) -reqrepcap(GiB/Mod1) 509.0reqvircap(GiB/Mod1) 0.0reptype eseopratio 0.0

Note: No overhead exists with the creation of the ESE repository. However, overhead exists when a TSE repository is created.


Creating ESE logical volumesTo 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 000aCMUC00025I mkfbvol: FB volume 000A successfully created.

dscli> showfbvol 000aName Testese001ID 000Aaccstate Onlinedatastate Normalconfigstate NormaldeviceMTM 2107-900datatype FB 512addrgrp 0extpool P16exts 1000captype DScap (2^30B) 1000.0cap (10^9B) -cap (blocks) 2097152000volgrp -ranks 0dbexts 0sam eserepcapalloc -eam managedreqcap (blocks) 2097152000realextents 0virtualextents 1000migrating 0perfgrp PG0migratingfrom -resgrp RG0tierassignstatus Unknowntierassignerror -tierassignorder Unknowntierassigntarget Unknown%tierassigned -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

dscli> lssestg -l p16extpool stgtype datastate configstate repcapstatus repcap(GiB/Mod1) vircap reptype repcapalloc vircapalloc opratio==================================================================================================================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

dscli> showsestg -reptype ese p16extpool P16stgtype fbdatastate Normalconfigstate Normalrepcapstatus below%repcapthreshold 0repcap(GiB) 509.0repcap(Mod1) -repcap(blocks) 1067534208repcap(cyl) -repcapalloc(GiB/Mod1) 0.0%repcapalloc 0vircap(GiB) 1000.0vircap(Mod1) -vircap(blocks) 2097152000vircap(cyl) -vircapalloc(GiB/Mod1) 1000.0%vircapalloc 100overhead(GiB/Mod1) -reqrepcap(GiB/Mod1) 509.0reqvircap(GiB/Mod1) 1000.0reptype eseopratio 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.


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.

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 p16Date/Time: February 10, 2014 2:05:17 PMName TesteseP16ID P16stgtype fbtotlstor (2^30B) 2121availstor (2^30B) 2116resvdstor (2^30B) 0rankgrp 0numranks 1numvols 1status below%allocated 0%available 99configured 2121allowed 2121available 2116allocated 5reserved 0%limit 100%threshold 20virextstatus full%virallocated 100%viravailable 0virconfigured 1000virallowed 1000viravailable 0virallocated 1000virreserved 0%virextlimit 100%virextthreshold 0encryptgrp -%allocated(ese) 0%allocated(rep) 0%allocated(std) 0%allocated(over) 0%virallocated(ese) 100%virallocated(tse) 0%virallocated(init) 0

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.)


%migrating(in) 0%migrating(out) 0numtiers 1etmanaged 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 000bCMUC00025I mkfbvol: FB volume 000B successfully created.


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 volumesNow, 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

dscli> lssestg -l p16Date/Time: February 10, 2014 2:45:02 PM EST IBM DSCLI Version: 7.7.30.163 DS: IBM.2107-75ZA571extpool stgtype datastate configstate repcapstatus repcap(GiB/Mod1) vircap reptype repcapalloc vircapalloc opratio==================================================================================================================P16 fb Normal Normal below 509.3 2000.0 ese 30.0 2000.0 3.9


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

dscli> showsestg -reptype ese p16...repcapalloc(GiB/Mod1) 30.0%repcapalloc 5vircap(GiB) 2000.0vircap(Mod1) -vircap(blocks) 4194304000vircap(cyl) -vircapalloc(GiB/Mod1) 2000.0%vircapalloc 100overhead(GiB/Mod1) -reqrepcap(GiB/Mod1) 509.3reqvircap(GiB/Mod1) 2000.0reptype eseopratio 3.9

Example 5-20 The showextpool command with data stored on the ESE volume

dscli> showextpool p16...totlstor (2^30B) 2122availstor (2^30B) 2083resvdstor (2^30B) 0rankgrp 0numranks 1numvols 2status below%allocated 1%available 98configured 2122allowed 2122available 2083allocated 39reserved 0%limit 100%threshold 0virextstatus full%virallocated 100%viravailable 0virconfigured 2000virallowed 2000viravailable 0virallocated 2000virreserved 0%virextlimit 100%virextthreshold 0encryptgrp -


%allocated(ese) 1%allocated(rep) 0%allocated(std) 0%allocated(over) 0%virallocated(ese) 100%virallocated(tse) 0%virallocated(init) 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 CLIWith 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 User’s Guide, GC27-4212.

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.

Note: Monitoring and management involve the threshold settings for the extent pool. Monitoring is determined by whether an ESE repository exists.


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 CLITo 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


dscli> chfbvol -cap 1500 000aCMUC00332W chfbvol: Some host operating systems do not support changing the volume size. Are you sure that you want to resize the volume? [y/n]: yCMUC00026I chfbvol: FB volume 000A successfully modified.


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).


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.

6


6.1 Management and monitoring capabilities

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.

Capacity on Demand (CoD) featureThis 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.

Important: In the DS8000, thin provisioning and the associated virtual capacity are manageable at the extent pool level.

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.


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.

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_percentageThe 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.

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.

Chapter 6. Managing and monitoring thin-provisioned volumes 77

Repository capacity threshold: - repository_threshold_percentageThis 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_percentageThis 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 PDTExtent Pool Capacity Threshold ReachedUNIT: Mnf Type-Mod SerialNm IBM 2107-922 75-03460Extent Pool ID: P1Limit: 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

Extent status Description Condition

10 %Available Real Cap. = 0 Full - extent pool full

1 Ext. Threshold >= %Avail. Real Cap. > 0 Exceeded - threshold exceeded

0 %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_20780Date/Time: August 13, 2009 12:51:07 PDT IBM DSCLI Version: 5.4.30.244 DS: IBM.2107-7520781Storage-complex IBM.2107-7520781 successfully modified.

dscli> showspDate/Time: August 13, 2009 12:51:57 PDT IBM DSCLI Version: 5.4.30.244 DS: -Name ATS_Mainz_20780desc ATS DS8000 S/N 75-20780acct -SNMP EnabledSNMPadd 9.155.87.211,9.155.66.14,9.145.243.185emailnotify Disabledemailaddr -emailrelay Disabledemailrelayaddr -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.


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.

7


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.

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.

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).


http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.cmds/doc/aixcmds3/aixcmds302.htm

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 DS8000Similar terms are used by the DS8000 and AIX to describe different objects or concepts.

DS8000 terminologyThe 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 terminologyAIX 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.

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.

Figure 7-2 AIX with JFS2 File System: 128 KB Files - 0 - 100% with 25% deletions

File System Usage and Storage Allocation

128 KB Files, 129 Root Directories, 16383 Total Directories, Concurrent Copies

0%

20%

40%

60%

80%

100%

0 100 200 300 400 500 600

Samples

FS %Usage Storage %Alloc

File System Usage and Storage Allocation

128 KB Files, 129 Root Directories, 16383 Total Directories, Concurrent Copies

0%

20%

40%

60%

80%

100%

0 200 400 600 800

Samples

FS %Usage Storage %Alloc


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 viewThere 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 volume’s 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.


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


Migration issuesThe 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


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.


http://www.ibm.com/services/us/index.wss/offerfamily/gts/a1028233

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 allocationFour 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.


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

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.

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.

ESE volume capacity Real (DS8000) extents used

10 GB 5

25 GB 5

50 GB 5

100 GB 6

Remember: One extent is 1024 MB or 1 GB.

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 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


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.


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.


Figure 7-13 Successful migration status

Migrating an empty standard volume to an ESE volumeIn 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

Migrating a non-empty standard volume to an ESE volumeWith 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.

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 5 5

25 GB 0% 25 GB 5 5

50 GB 0% 50 GB 5 5

100 GB 0% 100 GB 6 6

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.


Table 7-3 Non-empty standard volume to ESE volume

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 volumeWhen 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 4910Date/Time: August 24, 2009 15:26:09 PDT IBM DSCLI Version: 5.4.30.244 DS: IBM.2107-7520781Name itsotdmf10eseID 4910accstate Onlinedatastate Normalconfigstate NormaldeviceMTM 2107-900datatype FB 512addrgrp 4extpool P5exts 10captype DScap (2^30B) 10.0cap (10^9B) -cap (blocks) 20971520volgrp V12

Standard volume capacity

Standard volume capacity used

ESE volume capacity Real extents used after migration

10 GB 25% 10 GB 6

25 GB 25% 25 GB 10

50 GB 25% 50 GB 16

100 GB 25% 100 GB 30

10 GB 50% 10 GB 8

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


ranks 1dbexts 0sam ESErepcapalloc -eam rotatevolsreqcap (blocks) 20971520realextents 5virtualextents 10

dscli> initfbvol 4910Date/Time: August 24, 2009 15:26:26 PDT IBM DSCLI Version: 5.4.30.244 DS: IBM.2107-7520781CMUC00337W initfbvol: Are you sure that you want to submit the command releasespace for the FB volume 4910?[Y/N]:yCMUC00340I initfbvol: 4910: The command releasespace has completed successfully.

dscli> showfbvol 4910Date/Time: August 24, 2009 15:26:37 PDT IBM DSCLI Version: 5.4.30.244 DS: IBM.2107-7520781Name itsotdmf10eseID 4910accstate Onlinedatastate Normalconfigstate NormaldeviceMTM 2107-900datatype FB 512addrgrp 4extpool P5exts 10captype DScap (2^30B) 10.0cap (10^9B) -cap (blocks) 20971520volgrp V12ranks 0dbexts 0sam ESErepcapalloc -eam rotatevolsreqcap (blocks) 20971520realextents 0virtualextents 10

Migrating from a smaller standard volume to a larger ESE volumeIn 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.


Figure 7-14 Source standard volume and target ESE volume before the migration

Example 7-2 Volume status before the migration

dscli> showfbvol 4811Date/Time: 2009. kolovoz 24 17:20:25 PDT IBM DSCLI Version: 5.4.30.244 DS: IBM.2107-7520781Name itsotdmf25stdID 4811accstate Onlinedatastate Normalconfigstate NormaldeviceMTM 2107-900datatype FB 512addrgrp 4extpool P4exts 25captype DScap (2^30B) 25.0cap (10^9B) -cap (blocks) 52428800volgrp V12ranks 1dbexts 0sam Standardrepcapalloc -eam rotatevolsreqcap (blocks) 52428800realextents 25virtualextents 0

dscli> showfbvol 4913


Date/Time: 2009. kolovoz 24 17:20:39 PDT IBM DSCLI Version: 5.4.30.244 DS: IBM.2107-7520781Name itsotdmf100eseID 4913accstate Onlinedatastate Normalconfigstate NormaldeviceMTM 2107-900datatype FB 512addrgrp 4extpool P5exts 100captype DScap (2^30B) 100.0cap (10^9B) -cap (blocks) 209715200volgrp V12ranks 1dbexts 0sam ESErepcapalloc -eam rotatevolsreqcap (blocks) 209715200realextents 6virtualextents 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


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


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


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

dscli> showfbvol 4913Date/Time: 2009. kolovoz 24 18:08:16 PDT IBM DSCLI Version: 5.4.30.244 DS: IBM.2107-7520781Name itsotdmf100eseID 4913accstate Onlinedatastate Normalconfigstate NormaldeviceMTM 2107-900datatype FB 512addrgrp 4extpool P5exts 100captype DScap (2^30B) 100.0cap (10^9B) -cap (blocks) 209715200volgrp V12ranks 1dbexts 0sam ESErepcapalloc -eam rotatevolsreqcap (blocks) 209715200realextents 23virtualextents 100dscli>

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.


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


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 volumeTo 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.


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:

� 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:


� IBM DS8000 Series Command-Line Interface User’s 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


� 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






http://publib.boulder.ibm.com/infocenter/dsichelp/ds8000ic/index.jsp



Help from IBM

IBM Support and downloads

ibm.com/support

IBM Global Services

ibm.com/services


http://www.ibm.com/support/

http://www.ibm.com/support/

http://www.ibm.com/services/

http://www.ibm.com/services/

®

REDP-4554-01

INTERNATIONAL TECHNICALSUPPORTORGANIZATION

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

Redpaper™


Avoid allocating unused capacity

Read about new ESE repositorycapability and new controls

Understand applications and OS implications

Ever-increasing storage demands have a negative impact on an organization’s 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.

Back cover




ds8000 ese pool

Documents

ese logical volumes

ds8000 logical volumes

provisioned volumes

ese volumes575

ese volumes273

ds gui

new ese repositorycapability

ds cli support