• They are clustered designs that can be scaled horizontally
• Physical location of files is abstracted, allowing transparent migration & healing.
• They tend to heal themselves, reducing the need for service
• When a file is stored, they generate their own unique name for the file.
• The primary access model is via API, although secondary access via file systems is often supported
• They are immutable (files cannot be modified)

There is nothing in these valuable benefits about hashing or hash algorithms. These are the properties of Object Archival Storage Systems, which is a far more appropriate way of describing the breed. Dare I propose a new acronym OASS? Well the SNIA committee charged with standardizing these things is working hard on their own answer, and I'll defer to them. They used to call themselves CAS Solutions Initiative (CASSI), but they too have seen the light.

*A point of fact, but none of the CAS systems on the market today are actually CAS. CAS implies that the stored objects are accessed using a hash value computed from the file's contents. But there are not commercially available systems that do this today. For example, EMC's Centera uses a "C-clip" as the object handle, which is an amalgamation of a metadata record and the object hash. Other CAS/OS systems may use other more reliable ways of creating unique object identifiers that have nothing to do with the hash value.

So it would seem that the term "CAS" is meaningless, and we all hope it dies. But Object Storage is here to stay due to its propensity to solve unsolved problems of scale, reliability, and TCO. Somewhere in there is a role for computing hash values, but that feature will be less and less visible to customers, especially as Object Storage moves into a primary storage role.

In fact, I describe the various implementation as belonging to 4 categories, each of which will impose slightly different requirements on the storage and serving infrastructure:

1) Heritage archives:
Digital versions of historic or culturally important artifacts including video, images, documents, audio, etc. The data in the heritage archive represents in many cases the primary data of history. There is an increasing expectation that our children should be able to randomly surf this data as they form their own opinions of historic events, uncolored by the author of a textbook. Unfortunately many of these collections are already eroding to dust, unrecoverable from their original celluloid, silver nitrate, wax, or papyrus forms. Curators are now in a race to preserve these artifacts in digital form to protect them for future generations. Customers building heritage archives are particularly worried about cost, long-term data integrity (beyond the life of the media), and changes to their organizations required to support new digital workflows.

2) Compliance archives:
Compliance archives are digital repositories that are employed to support mandated data management policies handed down by various regulatory agencies. Regulations are imposed to insure well-documented business processes or to insure responsible and legal handling of individuals personal information. Example are SEC17a which requires immutability and auditability of trading records. HIPAA requires quality records retention, but it also works to protect individuals' data privacy. Sarbanes-Oxley does not mandate requirements for storage systems, but encourages good archival and audit practices that benefit from archive deployments. In Compliance applications, specific storage features such as immutability (WORM) and retention policies may be required to guarantee regulatory compliance.

3) Repurposing Archives:
These archives are typically found in media markets where an online archive provides the distribution leverage for generating incremental revenue or for lowering the cost of existing workflows. For some media companies with aging collections of master assets, preservation may also be a consideration. In many heritage archives, repurposing eventually turns out to provide tangible ROI as unpredicted distribution models provide opportunities for monetization. An excellent example is the GM Media Archives which were scanned and put online in a revenue generating asset management system. Another example is commonly found in film production where images, characters, and other assets are far easier to leverage for promotional materials or even future film productions if placed online in digital form.

4) Digital Distribution repositories:
Sometimes called origin servers, these are large scale storage systems that are built to facilitate more widespread digital distribution of assets that are otherwise available on library or enterprise shelves. Although digital library initiatives (see diglib.org) often concern themselves with preservation, the bulk of their material is simply books and journals that deserve the benefits of wide-area electronic distribution. It's not a surprise for example that Reed-Elsevier, the leading publisher of scientific journals deploys massive storage repositories. The digital distribution repository is also the core for next generation video-on-demand repositories being planned by broadcasters to provide random access into millions of hours of broadcast video or audio.

If we are to derive a specification for a storage system that is going to serve all of these applications, we need to tackle the following problems:
1) Initial deployments may be small, but grow significantly over time as ROI models are proven.
2) Capital budgets are the most significant barrier to archive deployment, and can vary from year-to-year.
3) The customer cannot afford sophisticated specialists for managing and maintaining the storage.
4) The collection may be too large to back up.
5) The life of the archive is longer than the life of the media. Migration should be easy and painless.
6) The life of the archive may be longer than the life of the data format.
7) Metadata is critical to finding and organizing data.
8) Cost and throughput of scanning efforts are continuing headaches.

So isn't the answer obvious?
We think so.

• Customers need more economical storage - to buy and own.
  The growth of on-line data, especially “fixed content” data is explosive. Many large scale customers have already passed the Petabyte boundary. For these environments, it's important to reduce the cost of the storage platform by using commodity components. Furthermore, large-scale storage today is more expensive to maintain than it is to purchase. Our customers simply cannot continue to add sysadmins as their data grows, and we need to dislocate conventiontional wisdom on "how many TB can be managed by a single Sysadmin?".
• Customers need improved reliability, availability and serviceability.
  In today's systems, these characteristics add to storage acquisition cost and to TCO. In the future, RAS needs to be improved while lowering both ownership and acquisition cost. That means a system that will tolerate lots of failures and heal itself appropriately without anyone needing to show up at 2am on a Saturday.
• Customers need transparent and non-disruptive scalability.
  Our customers are demanding “just in time” storage provisioning. Customers should only have to pay for storage as it's needed, and when it's deployed, scaling must not cause any disruption to the customer's application or clients. The problem is particularly acute for archival applications that scale steadily over time. Utility pricing (the ability to charge monthly just for the GB used), helps in this regard by eliminating the capital budgeting process for customers.
• Customers need to more easily organize and find data.
  It's clear that when we're talking about millions or hundreds of millions of files, the management and protection of metadata (data about the data) is as important as the management and protection of data. All storage systems today ignore application metadata, and in order to find their data, customers deploy external databases with search capability that carry substantial costs and management burden. If these data attributes are damaged or lost, the data itself is effectively lost. In addition to application attribute metadata, customers increasingly need to track whether the data is obsolete, current, ownerless, mission-critical, or in need of regulatory treatment. Today, expensive humans manage this, but the right system architecture can greatly simplify the process.

Honeycomb is a collection of hardware and software technologies that solve problems around next generation large-scale “data hungry” applications. That includes better methods for reliability, availability, scaling, and even searching and organizing data. Honeycomb's features were explicitly designed to address the customer problems articulated above. Currently, there is not a technology solution offered that addresses the following customer pain points effectively. Honeycomb is being designed to fill this void in the market. Honeycomb can be deployed as technology components that complement existing NAS products, or even as a standalone storage system.

Honeycomb demonstrates Sun's dedication to solving next generation data storage and management problems. It's not about simply beating competition, it's about giving customers strategically powerful data management solutions.

LAN-attached storage, inclulding NAS, CAS, HSM, and other file-based services calls upon the ultimate convergence of CPUs, OS, protocols, and networks. All of these things are core competencies of Sun. If we think towards next generation devices, we look to clustering, cryptography, consolidation and grid capabilities, load balancing, database, utility models, and a host of other areas, again all core competencies of Sun. The challenge is to make them all work together to solve unsolved customer problems. From Jonathan down we are committed to making that happen and that's why I work here.

I know what you're thinking..."the devil is in the details". Well, the details above are all I can provide until later this year when the NDA covers can be lifted a bit. Stay tuned for more.

Why use hashes? Well the real reason is that it simplifies the design for a storage system intended to be scalable by eliminating the need for distributed lock management across a clustered system. The serendipitous benefit is that it typically means objects are immutable, something useful for SEC-regulated applications.

So the term CAS is not particularly accurate, is aligned pretty strongly with EMC, and is not particularly benefits oriented so their term will die a slow death over the next couple years. In fact SNIA has already changed the naming of their respective committee away from CAS.