What you will learn from this tip: This tip takes a look at how to maximize your storage capacity utilization by finding orphaned data and storage that can in turn be re-allocated for another productive use.
A technique to maximize storage capacity utilization is to identify and make use of storage capacity being occupied by orphaned files and associated storage.
Orphaned storage exists in different forms and in various locations in most environments ranging from orphaned data in a database to orphaned storage in an email system or orphaned files in a network attached storage (NAS) or traditional file system. Orphaned storage can also exist in the form of unused or un-allocated LUNs, physical volumes or even individual disk drives on direct attached storage (DAS) and storage area network (SAN) (iSCSI or Fibre Channel) based storage.
Orphaned storage is any data, file, table space, object, file system, LUN, physical volume or storage device that appears to be in use but has been abandoned or forgotten about. Orphaned storage can result from application or system errors that have not been cleaned up after a restart, system maintenance, upgrade or other activity.
One challenge in finding orphaned storage and orphaned data is being able to identify if data is orphaned or not. Some files may appear as orphaned; however, they may be in line to be archived, in which case they should be migrated to some other storage medium. Likewise, some data files or storage volumes may appear to be allocated, having not been released after some previous use. The data or storage may not have been de-allocated if someone forgot to tell someone else that the storage is no longer being used, or that some documentation somewhere was not updated to indicate that the storage can be de-allocated and reprovisioned.
Another cause of orphaned storage is the result of system or application error. For example, over a period of time, inconsistencies can appear in databases or file systems requiring a repair operation to free up unused, yet allocated storage and index pointers. An example in Microsoft Windows is the chkdsk command, which can be used to identify and repair file system inconsistencies, including orphaned files or disk storage. UNIX-based systems can use the fsck command to identify and repair file system inconsistencies.
Tools to help detect orphaned storage are available from operating system, application and database vendors along with third-party vendors including EMC, HP, IBM, Microsoft, Monosphere, Novus, NTP, Oppsware and Quest, among others.
Consider the following eight items for finding and eliminating or adopting orphaned storage:
- Clean up temporary, scratch and work space on a regular basis.
- Run database, application specific and file system consistency checks.
- Utilize vendor tools or have your vendor check for orphaned devices.
- Leverage discovery and SRM tools to verify how storage is being used.
- Use configuration analysis tools to validate storage configurations.
- Look for files that appeared around the time a system or application error occurred.
- Have your DBAs check for duplicate data, orphaned rows or tables in databases.
- Institute policies and checklists as part of a clean-up after an application, operating system, server or storage upgrades to help catch and prevent orphaned storage.
Orphaned storage is a problem if ignored, because extra storage capacity and I/O performance are consumed to perform scans for backup, virus detection and other functions. Finding and eliminating, or adopting, orphaned data storage requires a time investment, including the use of tools to help discovery and analysis data. The time invested in looking for abandoned and un-utilized storage can help provide additional storage capacity. Take a look at your systems and see how much orphaned data storage you can find. Unless you are already aggressively looking for and have performed regular data and storage reclamation cleanup, I suspect that you will find some orphaned data storage.
Do you know…
About the author: Greg Schulz is founder and senior analyst with the IT infrastructure analyst and consulting firm StorageIO. Greg is also the author and illustrator of "Resilient Storage Networks" (Elsevier) and has contributed material to "Storage" magazine and other TechTarget venues.
This was first published in October 2006