Join me in New York for Storage Decisions, September 19 & 20

Later this month, I will be heading to New York for TechTarget’s Storage Decisions conference. This show does a good job on the editorial side, suggesting timely topics and bringing in independent voices like Howard Marks. I will have two presentations on data reduction and storage virtualization in the main conference track. Registration is free for qualified end-users, and I urge you to attend on September 19 and 20, 2011.

Reclaim Capacity with Data Reduction for Primary Storage

Depending on which industry study you read, most companies are wasting anywhere from 30% to 50% of their installed disk capacity, which translates into thousands of dollars spent with no effective return on investment. Storage vendors are beginning to provide tools that can help storage managers make the most of the disk they have installed. For example, data reduction for primary storage borrows data deduplication technology developed for backup and classic compression algorithms to help squeeze the air out of nearline and primary data and reduce its footprint. This session’s topics will include an overview of data reduction technologies and where they will have the greatest impact, what key storage vendors are offering in data reduction and an update on the major players, and the consequences of using primary data dedupe along with dedupe for backups. We’ll also look at the potential for vendor lock-in and consider why we’re reducing data in the first place.

Topics include:

• Introducing data reduction technologies
  • Compression: How it works and where it’s found
  • Deduplication: From single-instancing to variable block
  • Application-specific: Cracking open files
• Overview of data reduction products
• Where to use them
  • The capacity conundrum: Store less and reduce utilization
  • Ideal applications: Justifying the cost of data reduction
  • Side effects: Considering the impact on backup, replication, I/O workload and vendor lock-in

Storage Virtualization: Who’s Doing It and Why

Storage virtualization has been around for decades and, although research indicates that 70% of companies have already virtualized at least some of their installed block or file storage, most remain unaware of this technology. Grandiose schemes for comprehensive virtual SANs have given way to more practical host- and array-based virtualization technologies, and server virtualization has created a new opportunity to create a pool of storage. This session will look at the current state of storage virtualization, how to quantify its benefits and describe which approaches are best for particular environments, and also cover how storage virtualization compares to private storage clouds.

Topics include:

• Defining storage virtualization: What it is and where to find it
  • Abstraction of storage resources
  • Tiered storage
  • Flexibility
• Popular approaches to storage virtualization
  • SAN controllers
  • File virtualization
  • Volume managers
• The pool, the hypervisor and the cloud
  • The impact of server virtualization
  • Is this a private cloud?

Registration

You can see the future from here!

To register for Storage Decisions New York, just go to the TechTarget registration page.

Disclosure: TechTarget pays my expenses to attend and present at Storage Decisions, and has for many years. But they don’t pay me to present and I own the copyright on my session content. Happily, I license it all CC-by-NC-SA so I can give it out freely!

© sfoskett for Stephen Foskett, Pack Rat, 2011. | Storage Decisions New York: Capacity Optimization
This post was categorized as Enterprise storage, Personal, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

The commands are there to make CoreStorage do some cool things. But they don't quite work and aren't quite public...

Yesterday I noted that Apple included a full logical volume manager in Mac OS X 10.7 “Lion” without so much as a word. Today I am pleased to say that CoreStorage is much more functional than I had guessed, including a number of undocumented but seemingly functional commands for on-the-fly resizing of logical volumes as well as manipulation of physical volumes. Read on for the details, but please proceed at your own risk with these new commands!

You should probably read Mac OS X Lion Adds CoreStorage, a Volume Manager (Finally!) first!

CoreStorage Command Overview

The diskutil command is the core command line interface for CoreStorage, along with regular disk partitioning, AppleRAID, and other disk activities.

All CoreStorage functions use the “coreStorage” adverb, which can be abbreviated “cs”. For example, to show status of all CoreStorage volumes, one may type either:

diskutil coreStorage list

or

diskutil cs list

Typing just “diskutil cs” will show a list of nine supported “verbs”, but there are six other undocumented commands as well. Perhaps these are not fully functional (though all worked fine in my testing), or perhaps Apple simply wasn’t ready to expose them for end users to use.

I have grouped all 15 CoreStorage verbs by functional area, and note here which are officially listed and which are undocumented.

Informational Commands

• list – Show all CoreStorage volumes
• info[rmation] – Get detailed information about a physical volume

Conversion Commands

• convert – Convert a volume into a CoreStorage volume
• revert – Revert a CoreStorage volume to its native type

Logical Volume Group Commands

• create – Create a new CoreStorage logical volume group
• delete – Delete a CoreStorage logical volume group

Physical Volume (Disk) Commands

• resizeDisk (undocumented) – Resize a physical volume
• removeDisk (undocumented) – Remove a physical volume from a logical volume group
• addDisk (undocumented) - Add a new physical volume to a logical volume group

Logical Volume Commands

• createVolume – Create a new logical volume
• unlockVolume – Mount an existing encrypted logical volume
• changeVolumePassphrase – Change the encryption password for a logical volume
• deleteVolume (undocumented) – Delete a logical volume and all of its contents
• resizeVolume (undocumented) – Grow or shrink a logical volume (non-destructive)
• resizeStack (undocumented) – Grow or shrink a logical volume as well as the logical volume group and physical volume that supports it

CoreStorage Informational Commands

Two commands are for information about volumes and disks. Note that these only return information about CoreStorage volumes: Use the bare “diskutil list” and “diskutil info” commands for non-encapsulated storage.

list

Usage:  diskutil coreStorage list
        diskutil coreStorage list -plist
        diskutil coreStorage list UUID
List all current CoreStorage objects in a tree-like view.

info[rmation]

The verbs “info” or “information” get CoreStorage information by UUID.

CoreStorage Conversion Commands

These commands are used to convert a drive or volume to or from CoreStorage.

convert

Usage:  diskutil coreStorage convert
        MountPoint|DiskIdentifier|DeviceNode
        [-stdinpassphrase | -passphrase [passphrase]]
Convert a regular JHFS+ partition into a CoreStorage logical volume.
The file system must be mounted and resizable (i.e. Journaled HFS+).
Ownership of the affected disk is required.

Note that CoreStorage only functions on drives that meet the following criteria:

1. Partition type is GPT
2. Filesystem type is Journaled HFS+ (JHFS+)

Conversion from the command line is non-destructive (unlike using Disk Utility) and is the one shot you have to encrypt a volume. If you convert it without the passphrase, it will be placed in a LVF with no encryption and there is no command to encrypt it later!

revert

Usage:  diskutil coreStorage revert
        MountPoint|DiskIdentifier|DeviceNode|lvUUID
        [-stdinpassphrase | -passphrase [passphrase] | -recoverykeychain file]
Convert a CoreStorage logical volume back to its native type.
The file system must be mounted and resizable (i.e. Journaled HFS+).
Ownership of the affected disk and a passphrase (if encrypted) is required.

Reverting a CoreStorage volume completely returns it to its original state, including restoring the partition type and removing encryption. And it’s non-destructive. Slick!

CoreStorage Logical Volume Group Commands

These commands manipulate logical volume groups (LVGs) that have previously been created. Most use the “LVG Name”, which you can discover using the “diskutil cs list” command.

create

Usage:  diskutil coreStorage create lvgName
        MountPoint|DiskIdentifier|DeviceNode ...
Create a CoreStorage logical volume group from one more more disks.
The specified disks will become the initial set of PVs.
All existing data on the drive will be lost.
Ownership of the affected disk is required.
Example: diskutil coreStorage create MyLVG disk1

Note that this command is destructive. Say goodbye to your data or use the “cs convert” command! It automatically creates a PV for you.

delete

Usage:  diskutil coreStorage delete lvgUUID
Delete a CoreStorage logical volume group. All logical volumes will be removed.
Ownership of the affected disk is required.

This is destructive as well. Your volume will be returned to a usable state, but your data will be lost. Use “convert” and “revert” instead if possible!

CoreStorage Physical Volume (Disk) Commands

All physical volume commands are undocumented in Lion 10.7. Proceed with caution! But these are pretty cool, since they allow a LVG to span multiple physical disks!
PV commands use the word, “Disk”, which tells you a lot about what they are and what they do.
Note that the “pvUUID” and “lvgUUID” can be discovered in “diskutil cs list” and refer to the PV and LVG, respectively.

resizeDisk (undocumented)

Usage:  diskutil coreStorage resizeDisk pvUUID size
        [part1Format part1Name part1Size part2Format part2Name part2Size
         part3Format part3Name part3Size ...]
Resize a physical volume, which is one of one or more disks that provide storage
to a logical volume group. The logical volume group will have less or more
available space after this operation, if it was a shrink or grow, respectively.
If this is a shrink operation, you can optionally request that new partitions
be created in the newly-formed free space gap.
Example: diskutil coreStorage resizeDisk
         11111111-2222-3333-4444-555555555555 10g JHFS+ New 1g

This crazy-complicated command allows you to resize (both grow and shrink) active partitions non-destructively.

removeDisk (undocumented)

Usage:  diskutil coreStorage removeDisk pvUUID
Remove a physical volume from its CoreStorage logical volume group.
Ownership of the affected disks is required.
Example: diskutil coreStorage removeDisk 11111111-2222-3333-4444-555555555555

It is unknown what will happen if a used PV is removed from an LVG. Using a combination of addDisk and removeDisk should non-destructively move data from one physical disk to another, but I couldn’t get any of this to work.

addDisk (undocumented)

Usage:  diskutil coreStorage addDisk lvgUUID NewMemberDeviceName
Add a new physical volume to a CoreStorage logical volume group.
Ownership of the affected disks is required.
Example: diskutil coreStorage addDisk
         11111111-2222-3333-4444-555555555555 disk4

This should add additional physical capacity to an existing LVG, but I couldn’t get it to work. It always came back with “Error adding disk to CoreStorage Logical Volume Group: Invalid request (-69886)”

CoreStorage Logical Volume Commands

The logical volume commands are much more functional and friendly. Right now, the only way to really use these is to create a larger-than-needed LV and then shrink it and use the resulting space for new volumes, since you cannot yet fully create a LVG from scratch.

createVolume

This creates a new LV (and LVF) within an existing LVG, using space cleared by a previous resizeVolume or deleteVolume command. It appears to always create a new LVF rather than placing an LV within an existing one. And there are no LVF manipulation commands right now.

Usage:  diskutil coreStorage createVolume lvgUUID type name size
        [-stdinpassphrase | -passphrase [passphrase]]
Add a new logical volume to a CoreStorage logical volume group.

Type is the file system to initialize on the new logical volume. Valid types
are Journaled HFS+ or Case-sensitive Journaled HFS+ or their aliases.

Size is the amount of space to allocate from the parent logical volume group.
Valid sizes are floating-point numbers with a suffix of B(ytes), S(512-byte-
blocks), K(ilobytes), M(egabytes), G(igabytes), T(erabytes), P(etabytes),
or (%) a percentage of the current size of the logical volume group.

Example: diskutil coreStorage createVolume
         11111111-2222-3333-4444-555555555555 jhfs+ myLV 10g

unlockVolume

One of the seemingly-handier commands that isn’t really all that useful. It’s rare that you’ll want to do this alone. Use hdiutil to mount a volume instead.

Usage:  diskutil coreStorage unlockVolume lvUUID
        [-stdinpassphrase | -passphrase passphrase | -recoverykeychain file]
Unlock a logical volume that is encrypted and currently locked. You must
specify the logical volume by its CoreStorage UUID, because if it is locked
it is not online. A passphrase is mandatory: you must either supply it
interactively or with one of the above parameters.
Example: diskutil coreStorage unlockVolume 11111111-2222-3333-4444-555555555555

changeVolumePassphrase

A very handy command allowing you to change the passphrase of an existing VileVault 2 encrypted volume. This is probably the one verb that will be somewhat frequently used by the average user!

Usage:  diskutil coreStorage changeVolumePassphrase|passwd lvUUID
        [-recoverykeychain file] | [-oldpassphrase old]
        [-newpassphrase new] | [-stdinpassphrase]
Change an encrypted logical volume's password. Beyond the CoreStorage UUID,
you will be prompted interactively for parameters that you do not specify.
Parameters must be given in the above order.
Example: diskutil coreStorage changeVolumePassphrase
         11111111-2222-3333-4444-555555555555

resizeVolume (undocumented)

This appears to work fine. You can resize a volume (given its UUID) using this command, and you won’t even lose your data!

Usage:  diskutil coreStorage resizeVolume lvUUID size
Resize a logical volume, which is one of one or more disks that consume storage
out of a logical volume group. The logical volume group will have more or less
available space after this operation, if it was a shrink or grow, respectively.
Example: diskutil coreStorage resizeVolume
         11111111-2222-3333-4444-555555555555 10g

deleteVolume (undocumented)

This also works fine. Create a volume and you can delete it, as long as you get the right UUID from “diskutil cs list”.

Usage:  diskutil coreStorage deleteVolume lvUUID
Delete a logical volume.
Example: diskutil coreStorage deleteVolume 11111111-2222-3333-4444-555555555555

resizeStack (undocumented)

Probably the coolest undocumented command, resizeStack takes a complete 1:1:1:1 CoreStorage stack (PV:LVG:LVF:LV) and resizes everything non-destructively. You’re left with a fully-operational but smaller volume and partition. Nifty!

Usage:  diskutil coreStorage resizeStack lvUUID size
        [part1Format part1Name part1Size part2Format part2Name part2Size
         part3Format part3Name part3Size ...]
Resize both a logical volume and its underlying physical volume in a single
operation. The setup must be simple: Exactly one logical volume and one
related physical volume can, and must, exist.
If this is a shrink operation, you can optionally request that new partitions
be created in the newly-formed free space gap.
Example: diskutil coreStorage resizeStack
         11111111-2222-3333-4444-555555555555 10g JHFS+ New 1g

What’s Missing

These undocumented CoreStorage commands are eye-opening, since it shows that Apple really is working on a complete full-featured volume manager. But lots of functionality is lacking still:

1. You can’t create a logical volume group (LVG) by hand, adding multiple disks. It seems like you could, but not enough works yet.
2. There are no commands for manipulating logical volume families (LVFs), and they can’t even be specified when creating new logical volumes (LVs).
3. The physical volume (PV or disk) commands don’t seem to work. I guess that’s why they’re undocumented!
4. There are no advanced data protection features (mirror, snapshot, RAID, replicate)
5. There is no ability to specify where or how an LV is created or to move an LV from one LVF, PV, or LVG to another.

Stephen’s Stance

Clearly, CoreStorage is much more than a simple stack to support FileVault 2 encryption. Apple no only built an entire volume manager but also outfitted it with a good set of commands for configuration. Too bad it still lacks so many key features, and that so many of these are unofficial and hidden.

I feel confident that Mac OS X CoreStorage will become much more functional in the future, with complete volume manipulation and migration tools built into the GUI. For now, though, I must remind readers that this is all unofficial and you must proceed with caution. Back up your data, and do not assume that just because cool commands like resizeStack exist they are 100% ready for use!

Note: The pre-formatted text above comes straight from the diskutil command and its “help” responses. I discovered these undocumented verbs through trial and error and the judicial use of the “strings” command!

© sfoskett for Stephen Foskett, Pack Rat, 2011. | Undocumented CoreStorage Commands
This post was categorized as Apple, Enterprise storage, Everything, Personal, Terabyte home. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

You probably also want to read Key Storage Features in Mac OS X 10.7 “Lion” and Three Key Storage Features Missing in Mac OS X “Lion”

Apple’s Storage Story: A Mixed Bag

Apple’s file system, HFS+, is quite long in the tooth, dating back even before Mac OS X! Introduced in 1998′s Mac OS 8.1, HFS+ was extension of the original hierarchical file system (HFS) used by classic Mac operating systems back to System 2.1. But HFS+ has been extended and updated dramatically since those days, including the introduction of journaling in Mac OS 10.2.2, Unicode in 10.3, access control list-based file security in 10.4, and compression in 10.6.

The storage technology that underlies HFS+ has also improved dramatically over the years. Apple adopted EFI firmware and the GUID partition table (GPT) much more rapidly than the PC world. This allows Mac OS to scale to larger storage capacities than Windows systems, and has made the adoption of 4K sectors (so-called “advanced format”) much easier.  In fact, Apple is well ahead of the Windows world in these areas even as it lags with an outdated filesystem and no volume manager.

Mac OS never had much in terms of storage flexibility. Sure, AppleRAID brought some flexibility and redundancy to the server world, but the average Mac user never delved much into this technology. While Apple was asleep at the wheel, every other operating system vendor introduced a flexible volume manager. Even Microsoft, who is often criticized for slow innovation, is way ahead of Apple when it comes to data storage.

What is a volume manager? Volume managers add flexibility to operating system allocation of storage, acting as a virtualization layer between disks and file systems. This is important, since modern computer systems need to maintain a consistent filesystem image even as storage devices change. Volume managers like Symantec’s Veritas Volume Manager and the OSF LVM allow many operating systems this sort of flexible storage management. But Apple never had a volume manager of their own until the introduction of CoreStorage in Mac OS X “Lion”. Read more at Volume Management: Virtualizing Host Storage.

Introducing CoreStorage

All this has changed in Mac OS X 10.7 (“Lion”), however. Although Mac OS never did get ZFS, as was planned in 10.5, the storage enhancements found in 10.7 are getting awfully close in terms of features. Along with integrated file versions and full disk encryption comes a new technology called CoreStorage, including a full logical volume manager.

CoreStorage became necessary due to the inclusion of full volume encryption in Lion. Previously, Apple’s FileVault encryption technology relied on regular files to contain an encrypted filesystem. This worked fine until the need became apparent to encrypt an entire volume, whether it is the operating system disk or a removable drive. Although file-based technology can work in these scenarios, it is much less than ideal and also less than what competing operating systems offer.

But enabling full volume encryption requires an abstraction layer that Mac OS X simply did not have. Apple appears to have taken the long route, engineering a complete volume manager rather than hacking together some sort of kludgy mechanism. Although it is only used for FileVault 2 at the moment, CoreStorage appears to be a full volume manager that could, in the future, boast advanced features like mirroring, snapshots, and online storage migration.

CoreStorage Data Structures

CoreStorage implements a full complement of data structures but uses them in a very simplistic manner currently.

Apple did not simply copy existing volume manager semantics, and it does not appear that CoreStorage is an OEM version of someone else’s product. Rather, there are some intriguing new innovations present in CoreStorage that point to exciting possibilities in the future.

Like most volume managers, the basic building block of CoreStorage is the “logical volume group” (LVG). Illustrated in blue and purple above, each LVG takes storage from a “physical volume” (PV) and presents it to the operating system as a “logical volume” (LV). In this way, storage from a physical disk is abstracted before used by the operating system, allowing a great deal of flexibility. This is somewhat analogous to a hypervisor presenting a virtual machine interface.

Apple goes a step further than most volume managers, however, with the introduction of a new concept, the “logical volume family” (LVF). The LVF specifies properties that will be inherited by logical volumes that it contains. Currently, the only property specified by an LVF is FileVault encryption, but one can imagine that performance characteristics or redundancy could also be specified in this manner.

CoreStorage Today and Tomorrow

Today, when full volume FileVault encryption is used, Mac OS X automatically converts the desired volume into a CoreStorage volume, and encapsulating the partition as a PV, importing it into an LVG, and setting up an LVF and LV to contain the new filesystem. Only one of each element is created in this way, and all capacity is allocated at creation time. So there isn’t much use for the entire stack right now.

Using diskutil from the command line, one can create multiple logical volume families and logical volumes.

The Disk Utility GUI is fairly limited as well. Volumes can be converted to use FileVault 2, but all data is lost in this process. Only boot volumes can be corrected nondestructively through the GUI, and this happens in the Security & Privacy preference pane rather than Disk Utility. When boot volumes are encrypted, Apple gives users the option to “escrow” the decryption key online using their MobileMe or iCloud account, but this is not allowed for other volumes.

Currently, whenever a volume is converted to using FileVault, it is also automatically converted to CoreStorage behind the scenes. And if encryption is turned off in the GUI, it is converted back (“reverted”) to whatever it was before. But it’s possible to convert a volume on the command line without encryption, and to remove encryption without reverting. It’s also possible to manually manipulate CoreStorage in other ways.

In the future, it should be possible to manipulate storage much more fully.

The fact that Apple included a full volume manager of their own making indicates a bright future for CoreStorage. Already, it is possible to use the command line utility, diskutil to nondestructively convert and encrypt volumes. It is also possible to manipulate volume groups, logical volume families (indirectly), and logical volumes to a limited extent using diskutil.  One hopes that future versions of Mac OS X will include additional functionality, including the ability to manipulate physical volumes.

Stephen’s Stance

Either Apple has big plans for CoreStorage, or some Apple software engineer got way ahead of himself and designed a complete logical volume manager just to house FileVault data! I think the former is likely, since we know that Apple wanted to include ZFS, a flexible combination volume manager and file system, in Mac OS X 10.5 but was unable to due to licensing concerns. Now two versions later, Lion includes all of the basic technology needed to effectively manage storage volumes. It is likely that the GUI simply lags behind this core technology, and we will see additional functionality added in later operating system revisions.

Regardless of intent, Mac OS X now includes a fairly full storage stack, from EFI and GPT through CoreStorage and HFS+. No longer is Apple behind the times in terms of core storage (if you pardon the pun) features. Now if only we could get them to implement iSCSI!

© sfoskett for Stephen Foskett, Pack Rat, 2011. | Mac OS X Lion Adds CoreStorage, a Volume Manager (Finally!)
This post was categorized as Apple, Computer History, Enterprise storage, Everything, Features, Personal, Terabyte home. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

Join me in Chicago for Storage Decisions, June 21

Next month, I will be heading to Chicago for TechTarget’s Storage Decisions conference. This show does a good job on the editorial side, suggesting timely topics and bringing in independent voices like Howard Marks. I will have three presentations to give: Sessions on data reduction and storage virtualization in the main conference track, as well as a dinner discussion focusing on controlling the growth of data. Registration is free for qualified end-users, and I urge you to attend on June 21, 2011.

Reclaim Capacity with Data Reduction for Primary Storage

Depending on which industry study you read, most companies are wasting anywhere from 30% to 50% of their installed disk capacity, which translates into thousands of dollars spent with no effective return on investment. Storage vendors are beginning to provide tools that can help storage managers make the most of the disk they have installed. For example, data reduction for primary storage borrows data deduplication technology developed for backup and classic compression algorithms to help squeeze the air out of nearline and primary data and reduce its footprint. This session’s topics will include an overview of data reduction technologies and where they will have the greatest impact, what key storage vendors are offering in data reduction and an update on the major players, and the consequences of using primary data dedupe along with dedupe for backups. We’ll also look at the potential for vendor lock-in and consider why we’re reducing data in the first place.

Topics include:

• Introducing data reduction technologies
  • Compression: How it works and where it’s found
  • Deduplication: From single-instancing to variable block
  • Application-specific: Cracking open files
• Overview of data reduction products
• Where to use them
  • The capacity conundrum: Store less and reduce utilization
  • Ideal applications: Justifying the cost of data reduction
  • Side effects: Considering the impact on backup, replication, I/O workload and vendor lock-in

Storage Virtualization: Who’s Doing It and Why

Storage virtualization has been around for decades and, although research indicates that 70% of companies have already virtualized at least some of their installed block or file storage, most remain unaware of this technology. Grandiose schemes for comprehensive virtual SANs have given way to more practical host- and array-based virtualization technologies, and server virtualization has created a new opportunity to create a pool of storage. This session will look at the current state of storage virtualization, how to quantify its benefits and describe which approaches are best for particular environments, and also cover how storage virtualization compares to private storage clouds.

Topics include:

• Defining storage virtualization: What it is and where to find it
  • Abstraction of storage resources
  • Tiered storage
  • Flexibility
• Popular approaches to storage virtualization
  • SAN controllers
  • File virtualization
  • Volume managers
• The pool, the hypervisor and the cloud
  • The impact of server virtualization
  • Is this a private cloud?

Cutting Off Data Growth at the Disk

In this special dinner presentation, Stephen Foskett will discuss how to apply key data management technologies to arrest the growth of data. You’ll learn how capacity optimization technologies such as data deduplication and compression can reduce the trajectory of data growth as well as how tiering can reduce the cost of storage. Finally, Stephen will explore why the time may have finally come for active archiving and will leave you with practical ways to help your corporation better manage its data.

Note that space is limited for the dinner, which is sponsored by my friends at Dell.

Registration

To register for Storage Decisions Chicago, just go to the TechTarget registration page. Dinner guests will apparently be selected from that same pool of attendees.

Disclosure: TechTarget pays my expenses to attend and present at Storage Decisions, and has for many years. I also get a speaker fee for the dinner session.

© sfoskett for Stephen Foskett, Pack Rat, 2011. | Storage Decisions Chicago: All About Capacity Optimization
This post was categorized as Enterprise storage, Personal, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

I think this sentiment is just as valid today as when I posted it in 2008!

Although many discussions in the storage industry focus on the relative merits of one protocol or another, the conversation occasionally turns to the core issue at hand: We continue to patch together a system based on outdated concepts. Most storage protocols continue to mimic direct attached storage, and most of our so-called networks act as point to point channels. An ultra-modern virtualized storage infrastructure with all the latest bells and whistles still holds the concepts of block and file at its core. Whenever the storage industry has tried to bring about real storage management they have been stymied by a lack of context for data.

No amount of virtualization, and no new protocol, will fix this. Put simply, we need a storage revolution.

Channels, Blocks, and Files

Most innovation in the 1980s and early 1990s focused on moving storage out of the server. SCSI allowed disk to exist in a separate cabinet, RAID allowed multiple physical disks to become a single virtual one, and these were mixed to become the prototype storage array. Although SCSI allowed one-to-many connectivity, it was never a true peer-to-peer network, even once it was mixed with network concepts in the form of Fibre Channel.

Even today, SAN storage is focused on providing faster, more flexible, and feature-packed direct-attached storage. A modern virtual SAN hides a complex arrangement of caching, data protection, tiered storage, replication, and deduplication, masquerading the lot as a simple, lowly disk drive. It is sad but true that all of our work as an industry has been dedicated to recreating what we started with.

Networked file-based storage is no better. Although NAS devices have all the advanced features of their SAN cousins, they must present a simple file tree to the host to retain compatibility. File virtualization merely presents a larger homogenous tree.

Inside the server, too, features and complexity are hidden to retain a familiar file system format. Volume managers can do anything a virtualization device can, but must present their output as a simple (though virtual) disk drive. File systems, too, have added features but still present a familiar tree of mount points, inodes, and files. Even ZFS, possibly the most advanced combination of volume management and file system technology yet, must present a simple tree of storage to applications.

The Metadata Roadblock

This outdated paradigm, of disks and file trees, is ill-suited to today’s storage challenges. Data must be categorized so actions can be taken to preserve or destroy it based on policies. Data must be searchable so users and applications can find what they want. Data must be flexible so it can be used in new ways. Our antiquated notions are not capable of meeting these challenges.

One simple problem is that we lack context for our data. Most file systems merely assign to a file a name, location, owner, and security attributes. The most advanced can contain extended metadata, but this is rarely seen in practice since many applications cannot agree on how to use this data. Microsoft’s Office suite can store and share extended file attributes, for example, but these live inside the file rather than in the file system. The promise of expanded Office attributes is only realized in conjunction with a content management system like SharePoint which lies above the lowly file system.

What if the storage system could keep this data instead? What if it could logically group files according to project or client, mining keywords and authors, and maintaining revisions? These concepts are not new, having been implemented in content management systems for years, and certain elements appeared in file systems, like Apple’s HFS and VMS’ Files-11, for decades.

Cut Down the Tree

File metadata would allow advanced features, but truly taking advantage of them requires a more fundamental shift in the way applications access files. Rather than sticking to a traditional hierarchy of directories in a tree (which was, after all, simply a primitive metadata system), we should remove the tree altogether. Allow files to become data objects, identified by arbitrary attributes and managed according to an overarching policy.

This future vision is decidedly different from our current notion of storage, but is not so far off. Many organizations now rely on central data warehouses based on SQL-language relational databases. As many storage managers have grumbled, databases tend to ignore storage management concepts entirely, managing their own content independently.

But not all applications need a database back-end, so another initiative seeks to provide generic object storage for wider use. Called content-addressable storage or CAS, these devices have traditionally been used only for archival purposes, since that was their first market application. As vendors break free of proprietary interfaces in favor of open ones like XAM, CAS could transform storage itself by eliminating both file and block storage at once.

Similar concepts are already at work in the so-called Web 2.0 world. Non-traditional databases like Google BigTable, Amazon S3, and Hadoop allow massive scalability for object storage. API-sharing initiatives with many Web 2.0 companies can be seen as similar prototypical object storage frameworks. Any of these could be leveraged to provide a new world of data storage, and many are gaining traction even now.

Stephen’s Stance

Although traditional block storage is here to stay for disk drives, and tree-type file systems are likely to remain the foundation of operating system storage, new object-based concepts could change the world in fundamental ways. As applications become “web aware”, they also become object aware, increasing the likelihood of such a storage revolution. For the majority of applications, this new world would be a welcome one indeed.

© sfoskett for Stephen Foskett, Pack Rat, 2011. | We Need a Storage Revolution
This post was categorized as Apple, Computer History, Enterprise storage, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

First, let’s clarify just which products and capabilities Symantec is offering here:

• Veritas Storage Foundation version 5.0MP3 for Unix/Linux includes SmartMove and the Thin Reclamation API
• Veritas Storage Foundation for Windows 5.0 only includes SmartMove at this point, but it will be updated to include Thin Reclamation at some point in the coming year

Although there is no real information on Symantec’s web site about all this yet, Symantec’s director of Storage Management and High Availability, Sean Derrington, assures me that their software is available now. Although no compatible arrays are in end-user hands, 3PAR will update their T-Class firmware to support the API shortly, and HDS and HP are on the way as well.

Thin Aware Software

Next, contrary to what I inferred from the announcement, there is no native thin provisioning capability in the file system or volume manager. So the first item in my list is right out. However, the volume manager is now “thin aware”, which means that it will communicate up to the file system and down to the array to coordinate more effective use of space.

When the volume manager is used with Veritas File System (VxFS) on UNIX or NTFS on Windows Server 2003 or 2008, it will automatically keep track of deleted files and will pass this information down the stack to the array. This is a major piece of functionality to add, especially to NTFS, “hole punching” (like NetApp) to maximize thin provisioning.

The Storage Foundation tools have also been updated to properly report on thin provisioned volumes. For example, the following screenshot shows three disk devices where encl1 supports thin reclamation and encl0 does not.

# vxdisk list
DEVICE        TYPE   DISK          GROUP         STATUS
encl0_0       auto   encl0_0       mydg online   thin
encl1_0       auto   encl1_0       mydg online   thinrclm
encl1_1       auto   ecnl1_1       mydg online   thinrclm

Thin Reclamation API

The Veritas Thin Reclamation API allows the Storage Foundation volume manager and file systems to communicate with thin-capable arrays when data is deleted on thin-ified LUNs, maintaining their thin-ness as you go. When a file is deleted, the file system will communicate to the volume manager that that space is no longer needed. When the server administrator runs the “vxdisk reclaim” or “fsadm –R” commands, the volume manager will communicate this information to the array (using SCSI commands) that any vacated disk blocks can now be reclaimed. Symantec expects folks to set up a cron job to reclaim space, or perhaps just run it when they see the need.

This is brilliant stuff, and ought to make thin provisioning shine in terms of array utilization. In an environment of thin-enabled Veritas volumes and supported storage arrays, the amount of space used on an array will be awfully close to the amount of space used in the file systems. This is a massive win - a capacity gain of on the order of 50%-70% in an average environment!

For more on this topic, see my recent post on storage utilization

If the storage array fully supports Symantec’s API, the tools will also report physically allocated storage behind thin and thin_reclaim devices.

# vxdisk –o thin list
DANAME        DISK SIZE(Mb)        PHYS_ALLOC(Mb)       DISK GROUP TYPE
encl0_0       2000                 50 mydg              thin
encl1_0       200                  50 mydg              thinrclm
encl1_1       500                  500 mydg             thinrclm

SmartMove

SmartMove is Symantec’s new capability for online migration from “thick” to thin LUNs. It is included in Storage Foundation for Unix/Linux and Windows and works with any thin storage array, not just those that support the API. This is basically a tweak to the old storage migration support we have all known and relied on in Veritas Storage Foundation for over a decade, except that it’s smart enough to not request blocks that it won’t use. One could theoretically “SmartMove” a volume regularly to reclaim space without using the API at all, but those commands are sure a lot simpler.

Note that SmartMove speeds up migration too, even for thick volumes! When you use a SmartMove-enabled version of Storage Foundation to move a volume, it will only send the blocks that have changed over the wire. This reminds me a little of VMware’s new I/O deduplication capability talked about at VMworld, but it’s focused only on migrations, not other I/O situations.

For more on this topic, see my recent post on VMware vStorage

The Plot Thickens

So I was wrong about one item, but the other two remain true. Is Symantec’s new capability a winner? I give it a silver medal – it’s good stuff, but some issues remain.

1. My primary concern remains – thin provisioning does nothing to address the lack of storage management that is so prevalent. It enables greater utilization of capacity, but does nothing to control how that capacity is used. This isn’t a beef with Symantec’s Veritas Storage Foundation or 3PAR or HDS or EMC or anyone in the thin industry, really. Instead, it is a wake-up call to all of the storage organizations out there who have filesystems full of uncontrolled junk!
2. My second concern is the lack of capacity management. Thin provisioning is a lie, promising more capacity than is available. This might be acceptable in certain controlled circumstances like operating system or application volumes, but telling end users that they have plenty of available space is a recipe for disaster. Storage use is like air – it expands to fill all available volume. Without capacity management, your thin volumes will be “overdrawn” and your storage “account” will be bankrupt.
3. Then there is the issue of proprietary APIs versus standards. Let me say right away that I always support standards over proprietary technology. But, at the same time, given the choice between nothing and something, I’ll take the proprietary API. Thin provisioning is a good idea with poor implementation. This API helps to make it useful in the real world, and having a market leader like Symantec behind it makes it all the more relevant. I certainly hope the entire storage industry will come up with a standard thin API, and when that happens I hope Symantec will support it. Until then, at least we have something.

I will be writing more about thin provisioning in the coming weeks. Until then, I continue to applaud Symantec, 3PAR, HDS, and HP for their work in making this technology somewhat more practical. Now how about VMware, Microsoft, Sun, and the Linux guys get some thin technology going, too?

See my posts on Gestalt IT for similar enterprise IT infrastructure commentary

© sfoskett for Stephen Foskett, Pack Rat, 2008. | Symantec’s Thin API: The Plot Thickens
This post was categorized as Enterprise storage, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.