Applying XAM processes

Abstract

A method is used in applying XAM processes. A set of content is received via any of a file system interface, a block based interface, an object based interface to an object addressable data storage system. An object derived from the set of content and having an object identifier is stored in the object addressable data storage system. The object is made available for retrieval via the object based interface using the object identifier.

Claims

1. A method for use in applying XAM processes, the method comprising: receiving a set of content via one of multiple different interfaces at an object addressable data storage system, wherein the storage system includes a file system interface, a block based interface, and an object based interface, wherein receiving includes attaching metadata to the set of content as it is received via one of the multiple different interfaces at the object addressable data storage system; converting the set of content received via one of multiple different interfaces, wherein converting includes converting content received via the file system interface into a set of local files and asynchronously converting the local files to an XSet, converting content received via the block based interface into a set of local files and asynchronously converting the local file to an XSet, and content received via the object based interface includes converting the received content into local files in an object store and replicating an XSet as received; storing, in the object addressable data storage system, an object derived from the set of content received via any of the file system interface, the block based interface, and the object based interface, the object having an object identifier, wherein storing includes unifying the derived object and storing the derived object in a unified object store; utilizing XAM processes to index the metadata and the derived object from the set of content received via any of the file system interface, the block based interface, and the object based interface; making the derived object available for retrieval via the object based interface using the object identifier; and providing a singular, unified view of the metadata and the derived object derived from the set of content received via any of the file system interface, the block based interface, and the object based interface.

2. The method of claim 1, wherein the object addressable data storage system comprises indexed storage using XAM processes.

3. The method of claim 1, wherein the object addressable data storage system uses a unified, canonical format to house content arriving via any of the file system interface, the block based interface, and the object based interface.

4. The method of claim 1, wherein in the object addressable data storage system the set of content can be viewed using a XAM process.

5. The method of claim 1, wherein the set of content is converted to a local file supported by file system software and the local file is converted to an XSet and stored using XAM.

6. The method of claim 1, wherein the set of content is converted to an XSet and path and filename are included in the XSet as nonbinding metadata.

7. The method of claim 1, wherein the set of content is converted to an XSet and replication is applied to the XSet.

8. The method of claim 1, wherein the set of content is converted to an XSet and the XSet is visible through the object based interface.

9. The method of claim 1, wherein the set of content, if received via the object-based interface, is visible only via the object-based interface.

10. A system for use in applying XAM processes, the system comprising a processor and memory configured to: receive a set of content via one of multiple different interfaces at an object addressable data storage system, wherein the storage system includes a file system interface, a block based interface, and an object based interface, wherein receive included attach metadata to the set of content as it is received via one of the multiple different interfaces at the object addressable data storage system; convert the set of content received via one of multiple different interfaces, wherein convert includes convert content received via the file system interface into a set of local files and asynchronously converting the local files to an XSet, convert content received via the block based interface into a set of local files and asynchronously convert the local file to an XSet, and content received via the object based interface includes convert the received content into local files in an object store and replicate an XSet as received; store, in the object addressable data storage system, an object derived from the set of content received via any of the file system interface, the block based interface, and the object based interface, the object having an object identifier, wherein store includes unify the derived object and store the derived object in a unified object store; utilize XAM processes to index the metadata and the derived object from the set of content received via any of the file system interface, the block based interface, and the object based interface; make the derived object available for retrieval via the object based interface using the object identifier; and provide a singular view of the metadata and the object derived from the set of content received via any of the file system interface, the block based interface, and the object based interface.

11. The system of claim 10, wherein the object addressable data storage system comprises indexed storage using XAM processes.

12. The system of claim 10, wherein the object addressable data storage system uses a unified, canonical format to house content arriving via any of the file system interface, the block based interface, and the object based interface.

13. The system of claim 10, wherein in the object addressable data storage system the set of content can be viewed using a XAM process.

14. The system of claim 10, wherein the set of content is converted to a local file supported by file system software and the local file is converted to an XSet and stored using XAM.

15. The system of claim 10, wherein the set of content is converted to an XSet and path and filename are included in the XSet as nonbinding metadata.

16. The system of claim 10, wherein the set of content is converted to an XSet and replication is applied to the XSet.

17. The system of claim 10, wherein the set of content is converted to an XSet and the XSet is visible through the object based interface.

18. The system of claim 10, wherein the set of content, if received via the object-based interface, is visible only via the object-based interface.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) Additional features and advantages of the invention will be described below with reference to the drawings, in which:

(2) FIG. 1 is a diagram of data structures for use in applying XAM processes; and

(3) FIGS. 2-6 are block diagrams of one or more data storage systems for use with the data structures of FIG. 1.

(4) While the invention is susceptible to various modifications and alternative forms, a specific embodiment thereof has been shown in the drawings and will be described in detail. It should be understood, however, that it is not intended to limit the invention to the particular form shown, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the scope of the invention as defined by the appended claims.

DETAILED DESCRIPTION OF EMBODIMENT(S)

(5) Described below is a technique for use in applying XAM processes, which technique may be used to provide, among other things, indexed storage using XAM processes. In at least one implementation, indexed storage refers to a storage system that uses XAM processes to index and view all data arriving into a storage system via any protocol. Conventionally, multiprotocol boxes lack the ability to attach universal metadata to content arriving on different protocols, and lack the ability to provide a singular view of content and associated metadata. By Contrast, for example, by use of the technique described herein, an indexed storage system can be implemented that has a unified, canonical format (XAM XSets) to ultimately house content arriving to the indexed storage system via any or nearly any protocol. In such an indexed storage system, this unified format can be viewed on the front end (i.e., through an application interface to the storage system) using an industry standard process (XAM) and it can also support Centera/XAM processes on the back-end (i.e., with the storage system) as well (e.g., retention, replication, single instancing).

(6) Referring to FIG. 2, shown is an example of an embodiment of a computer system that may be used in connection with performing the techniques described herein. The computer system 10 includes one or more data storage systems 12 connected to server or host systems 14a-14n through communication medium 18. The system 10 also includes a management system 16 connected to one or more data storage systems 12 through communication medium 20. In this embodiment of the computer system 10, the management system 16, and the N servers or hosts 14a 14n may access the data storage systems 12, for example, in performing input/output (I/O) operations, data requests, and other operations. The communication medium 18 may be any one or more of a variety of networks or other type of communication connections as known to those skilled in the art. Each of the communication mediums 18 and 20 may be a network connection, bus, and/or other type of data link, such as a hardwire or other connections known in the art. For example, the communication medium 18 may be the Internet, an intranet, network or other wireless or other hardwired connection(s) by which the host systems 14a 14n may access and communicate with the data storage systems 12, and may also communicate with other components (not shown) that may be included in the computer system 10. In one embodiment, the communication medium 20 may be a LAN connection and the communication medium 18 may be an iSCSI or fibre channel connection.

(7) Each of the host systems 14a-14n and the data storage systems 12 included in the computer system 10 may be connected to the communication medium 18 by any one of a variety of connections as may be provided and supported in accordance with the type of communication medium 18. Similarly, the management system 16 may be connected to the communication medium 20 by any one of variety of connections in accordance with the type of communication medium 20. The processors included in the host computer systems 14a-14n and management system 16 may be any one of a variety of proprietary or commercially available single or multi-processor system, such as an Intel-based processor, or other type of commercially available processor able to support traffic in accordance with each particular embodiment and application.

(8) It should be noted that the particular examples of the hardware and software that may be included in the data storage systems 12 are described herein in more detail, and may vary with each particular embodiment. Each of the host computers 14a-14n, the management system 16 and data storage systems may all be located at the same physical site, or, alternatively, may also be located in different physical locations. In connection with communication mediums 18 and 20, a variety of different communication protocols may be used such as SCSI, Fibre Channel, iSCSI, and the like. Some or all of the connections by which the hosts, management system, and data storage system may be connected to their respective communication medium may pass through other communication devices, such as a Connectrix or other switching equipment that may exist such as a phone line, a repeater, a multiplexer or even a satellite. In one embodiment, the hosts may communicate with the data storage systems over an iSCSI or a fibre channel connection and the management system may communicate with the data storage systems over a separate network connection using TCP/IP. It should be noted that although FIG. 2 illustrates communications between the hosts and data storage systems being over a first connection, and communications between the management system and the data storage systems being over a second different connection, an embodiment may also use the same connection. The particular type and number of connections may vary in accordance with particulars of each embodiment.

(9) Each of the host computer systems may perform different types of data operations in accordance with different types of tasks. In the embodiment of FIG. 2, any one of the host computers 14a-14n may issue a data request to the data storage systems 12 to perform a data operation. For example, an application executing on one of the host computers 14a-14n may perform a read or write operation resulting in one or more data requests to the data storage systems 12.

(10) The management system 16 may be used in connection with management of the data storage systems 12. The management system 16 may include hardware and/or software components. The management system 16 may include one or more computer processors connected to one or more I/O devices such as, for example, a display or other output device, and an input device such as, for example, a keyboard, mouse, and the like. A data storage system manager may, for example, view information about a current storage volume configuration on a display device of the management system 16.

(11) In at least one embodiment, the one or more data storage systems 12 of FIG. 2 may be an appliance with hardware and software for hosting the data storage of the one or more applications executing on the hosts 14a-14n. The appliance may include one or more storage processors and one or more devices upon which data is stored. The appliance may include software used in connection with storing the data of the hosts on the appliance and also software used in connection with techniques described in following paragraphs which are part of a common software environment.

(12) In another embodiment, the data storage systems 12 may include one or more data storage systems such as one or more of the data storage systems offered by EMC Corporation of Hopkinton, Mass. Each of the data storage systems may include one or more data storage devices, such as disks. One or more data storage systems may be manufactured by one or more different vendors. Each of the data storage systems included in 12 may be inter-connected (not shown). Additionally, the data storage systems may also be connected to the host systems through any one or more communication connections that may vary with each particular embodiment and device in accordance with the different protocols used in a particular embodiment. The type of communication connection used may vary with certain system parameters and requirements, such as those related to bandwidth and throughput required in accordance with a rate of I/O requests as may be issued by the host computer systems, for example, to the data storage systems 12. It should be noted that each of the data storage systems may operate stand-alone, or may also be included as part of a storage area network (SAN) that includes, for example, other components such as other data storage systems. Each of the data storage systems may include a plurality of disk devices or volumes. The particular data storage systems and examples as described herein for purposes of illustration should not be construed as a limitation. Other types of commercially available data storage systems, as well as processors and hardware controlling access to these particular devices, may also be included in an embodiment.

(13) In such an embodiment in which element 12 of FIG. 2 is implemented using one or more data storage systems, each of the data storage systems may include code thereon for performing the techniques as described herein for the common software environment. Servers or host systems, such as 14a-14n, provide data and access control information through channels to the storage systems, and the storage systems may also provide data to the host systems also through the channels. The host systems may not address the disk drives of the storage systems directly, but rather access to data may be provided to one or more host systems from what the host systems view as a plurality of logical devices or logical volumes (LVs). The LVs may or may not correspond to the actual disk drives. For example, one or more LVs may reside on a single physical disk drive. Data in a single storage system may be accessed by multiple hosts allowing the hosts to share the data residing therein. An LV or LUN (logical unit number) may be used to refer to the foregoing logically defined devices or volumes.

(14) In following paragraphs, reference may be made to a particular embodiment such as, for example, an embodiment in which element 12 of FIG. 2 is an appliance as described above. However, it will be appreciated by those skilled in the art that this is for purposes of illustration and should not be construed as a limitation of the techniques herein.

(15) The common software environment may include components described herein executing on each data storage system. Each of the data storage systems may have any one of a variety of different hardware and software platforms. For example, a first data storage system may include the common software environment with a first operating system and underlying hardware. A second data storage system may include the common software environment with a different operating system and different underlying hardware.

(16) The common software environment includes a framework which may be implemented using APIs (application programming interface) and other code modules. The APIs may implement the underlying functionality which varies with the different possible data storage system hardware and software platforms.

(17) With reference to FIG. 3, in an example implementation, system 12 is a multi-interface, multi-protocol storage system that may be used as a general purpose storage system and/or as a special purpose storage system, e.g., an archival storage system that integrates multiple different types of archival and backup technology into one. In at least one case, system 12 has a component architecture and is Linux based.

(18) System 12 has an application interface 203, a storage system interface 213, and file system and software 223. For use in communicating with applications, e.g., running on host 14a, application interface 203 provides three interfaces: XAM API 210 (with Centera Protocol VIM loaded) which is object based; file system based interface 220; and block-based (e.g., SCSI Tape Target) interface 230. (Vendor Interface Modules (VIMs) are software modules that have a standard interface that converts XAM requests into native requests supported by the underlying hardware systems. For example, a XAM API call that is routed to the Centera Protocol VIM is converted to the Centera protocol and sent to Centera functionality.)

(19) For communicating with underlying storage system resources, storage system interface 213 includes Centera Protocol 240, NFS/CIFS 250, and virtual tape library (VTL) 260 interfaces corresponding to the XAM 210, file system 220, and block-based 230 interfaces respectively. (Common Internet File System (CIFS) is a network file access protocol.) With reference to “the OAS applications” as defined further below, file system and software 223 includes CSO (Centera Software Only) software 275 and other software used as described below with Centera Protocol interface 240, and High Performance File System software 265 and Centera Universal Access (CUA) services software 270 for use as described below with interfaces 250, 260.

(20) With respect to data ingest mechanics of system 12, data may be ingested through XAM API 210, file system interface 220, and block-based interface 230.

(21) With reference now to FIG. 4, now described is an example of ingestion through XAM API 210. An application (e.g., running on host 14a) creates XAM object (XSet) and stores it using XAM API 210. CSO software 275 converts the resulting data stream into local files in object store 255 and replicates 235 the XSets as they are ingested. In at least some cases, such object based replication means that no backup is required. Also, this leverages “universal migrator” capabilities of XAM such that a replication target may be any XAM device. Metadata (and optionally, object content) is indexed for later query access using index 245. Data is de-duplicated 225 asynchronously in place. Thus, if backup is desired, de-duplication results in reduced network (e.g., wide area network) traffic. Additional de-duplication can also be provided by integrating de-duplication technology into the VIM.

(22) With reference now to FIG. 5, now described is an example of ingestion through file system interface 220. An application (e.g., running on host 14a) creates a file using file system interface 220. NFS/CIFS interface 250 converts the resulting data stream to a local file supported by High Performance File System software 265. CUA services 270 serves as an application communicating with XAM API 210 and asynchronously causes the local file to be converted to an XSet and stored using XAM API 210. On conversion, path and filename are included in the XSet as nonbinding metadata. Time before such conversion is tunable to accommodate service level agreements about replication speed.

(23) Thereafter this XSet is handled in the same way as the XSet described in the above example of ingestion through XAM API 210, including use of object store 255 and index 245 and appropriate indexing, replication, and de-duplication as described above. XUIDs are stored by High Performance File System software 265 to enable continued access to data after XAM conversion.

(24) Note that in at least one implementation, data ingested via XAM only (as described above in connection with FIG. 4) is not visible through file system interface 220 and NFS/CIFS interface 250, but data ingested via file system interface 220 and NFS/CIFS interface 250 is visible through XAM API 210.

(25) With reference now to FIG. 6, now described is an example of ingestion through block-based interface 230, wherein the example relates to a virtual tape library application. An application (e.g., running on host 14a) writes a file to SCSI tape (virtual, in this case) using interface 230. Virtual Tape Library interface 260 converts the resulting data stream to a local file supported by High Performance File System software 265. CUA services 270 serves as an application communicating with XAM API 210 and asynchronously causes the local file to be converted to an XSet and stored using XAM API 210.

(26) Thereafter this XSet is handled in the same way as the XSet described in the above example of ingestion through XAM API 210, including use of object store 255 and index 245 and appropriate indexing, replication, and de-duplication as described above.

(27) Note that in at least one implementation, data ingested via XAM only (as described above in connection with FIG. 4) is not visible through block-based interface 230 and Virtual Tape Library interface 260, but data ingested via block-based interface 230 and Virtual Tape Library interface 260 is visible through XAM API 210.

(28) In at least one implementation, data ingested via file system interface 220 and NFS/CIFS interface 250 is not visible through block-based interface 230 and Virtual Tape Library interface 260, and data ingested via block-based interface 230 and Virtual Tape Library interface 260 is not visible through file system interface 220 and NFS/CIFS interface 250.

(29) In at least one implementation, all data ingested by system 12 via any interface is visible at least through XAM API 210.

(30) In at least one implementation, all data ingested by system 12 via any interface is unified in object store 255 and is indexed locally with index 245 to support scalable query and processing. With respect to unification of stored (e.g., archived) data, all data, universal services are available. XAM provides a job model to enable arbitrary jobs to be able to run on the data. These jobs include:

(31) Query: A subset of SQL based on Documentum's DSQL is the query language used by XAM. XAM defines query support for both data and metadata.

(32) Analysis: XAM fully supports mime types for all elements of data and metadata stored in its objects. Any rich information based on file type will be passed along to the XAM self describing format, allowing contextual analysis of data (e.g., face recognition on images files—this can be done by other applications due to the self-describing nature of the XSet).

(33) Processing: Actions can be taken based on query and analysis. For example, a policy based job can be nm that migrates all data on the system that has not been accessed for two years.

(34) With respect to universal retention and disposition, default retention and disposition rules can be applied to NFS/CIFS and block-based (tape data) on ingest. Subsequent to ingest, rich policy management can be applied to this data through the XAM interface, such as litigation hold and release, retention policy review and modification on a per object basis or through wholesale policy management, and auto-disposition policy, which specifies what to do with content when its retention policy expires, and what to do when it is deleted.

(35) With respect to universal migration, XAM provides a mechanism for migrating files from performance based pre-provisioned locations to location independent archived storage. True Hierarchical Storage Management (HSM) and policy driven lifecycle management is enabled. A self describing canonical format can include references to key stores, authentication warehouses, and policy information in a portable fashion. Any XAM device can be used as a migration destination.

(36) Thus, in accordance with the technique described herein, no matter which protocol is used to ingest data, the data is stored using object-based storage processes, in combinations of objects and metadata, so that under the XAM protocol content can be stored and metadata can be associated along with it, and a unique object identifier can be returned back.

(37) System 12 has object-based, file-based, and block-based capabilities all collapsed into one storage device that advertises all three protocols so that there are three different ways to ingest data into the storage system.

(38) Host 14a has an application that has integrated with the XAM API and creates an XSet object and stores it using the XAM API. The XSet object includes content, e.g., x-ray information, doctor's notes, patient information, and is sent down through the XAM API to Centera protocol. The resulting data stream that comes in is put into local files (object store 255) and can be replicated immediately. At least the metadata that comes down in this object can be indexed and stored in a search and index type of database for queries later to find objects. Deduplication software 225 acts on store 255 such that as files are loaded into store 255, hashes are derived from the content and are compared to determine whether store 255 already has the content so that it need not be stored again.

(39) With respect to the file system interface, the application creates a file, e.g., using commands fopen, write, close, and inside system 12 the file is stored as local file. CUA services converts the local file into a XAM XSet by calling XAM API and presenting the file and directing XAM API to turn the file into an object. Subsequently the same set of events occur that are experienced whenever writing directly to XAM API takes place, e.g., same replication, same deduplication possibilities. Accordingly, no matter which protocol is used, a same form of replication is used on the back end.

(40) Thus, for example, advantageously, if a file needs to be retained for seven years, an application or user can access the XAM API, request the object for the file (e.g., x-ray data) that was stored, get the object, and turn retention on for seven years; subsequently within the seven years, when someone tries to delete the file, it cannot be deleted. Thus, files can be accessed as objects since system 12 turns the files into objects as soon as the files come into the system, and making the objects available via a different protocol (e.g., XAM). This also has other advantages such as shredding, wherein an application or user can go to the XSet via XAM API and turn shredding on for a particular object, and if someone deletes the corresponding file via the file system, system 12 will shred it.

(41) Also, when a file is deleted, system 12 leaves behind a reflection indicating time and date and user for the deletion, so that, via the XAM API, an application or user can do a query of everything that has been deleted in last hour or over another time period.

(42) In a specific example, a business scans or accepts mortgage applications, and stores them via the file system. Rules or regulations state how long the business must keep them or make them immutable (no alterations). If the business's document workflow application requires storing files in a file system and it is impractical or difficult to integrate the application with the XAM API, system 12 helps the business with compliance with the rules or regulations.

(43) After system 12 has completed storing a new file as an object in store 255, the file system of High Performance File System 265 stores only the XUID (object ID) corresponding to the file, so that, for example, if an application running on host 14a needs to open the file, High Performance File System software uses the object ID to retrieve the corresponding object from XAM API, unpacks the file from the object, and returns the file to the application.

(44) Similarly, in the case of SCSI tape, a file is written by the application to a SCSI tape device (as virtually presented by system 12), VTL converts the file to the local file system, and CUA services causes it to be converted to a XAM XSet and the remaining steps are same the same as in the case of the file system.

(45) No matter which protocol is used for ingestion, indexing is provided, so that if, for example, a file is lost according to the VTL interface, an application or user can check for it via the XAM API and can restore it via the XAM API. In at least one implementation, indexing is accomplished by making a pass over the file and pulling out keywords and indexing them, i.e., indexing content on the fly, along with any metadata that comes with file, e.g., where is it in the file system, SCSI tape number.

(46) When CUA services indicates it has a file that was backed up to tape that is to be packaged as an XSet object, additional metadata may be stored, e.g., tape number, SCSI ID.

(47) XAM API supports searching through a pool of objects by keyword, and system 12 may implement index 245 as local storage.

(48) Since all objects can be accessed through XAM API regardless of the protocol used for ingest, such objects can be supported by XAM's set of services, e.g., query processing, application of policies regarding universal retention, litigation hold, disposal. In addition, such objects can benefit from universal migration, since XAM is vendor neutral migration such that objects when exported are converted to a vendor neutral format (e.g., the self describing canonical format) which can be ingested by any other XAM device. This can be used, e.g., for technology refresh or to a different revision of the same file system.

(49) The above-described embodiments of the present invention can be implemented on any suitable computer, and a system employing any suitable type of storage system. Examples of suitable computers and/or storage systems are described in the patent applications listed below in Table 1 (collectively “the OAS applications”), each of which is incorporated herein by reference. It should be appreciated that the computers and storage systems described in these applications are only examples of computers and storage systems on which the embodiments of the present invention may be implemented, as the aspects of the invention described herein are not limited to being implemented in any particular way.

(50) TABLE-US-00001 TABLE 1 Title Ser. No. Filing Date Content Addressable 09/236,366 Jan. 21, 1999 Information, Encapsulation, Representation, And Transfer Access To Content 09/235,146 Jan. 21, 1999 Addressable Data Over A Network System And Method For 09/391,360 Sep. 7, 1999 Secure Storage Transfer And Retrieval Of Content Addressable Information Method And Apparatus For 10/731,790 Dec. 9, 2003 Data Retention In A Storage System Methods And Apparatus For 10/731,613 Dec. 9, 2003 Facilitating Access To Content In A Data Storage System Methods And Apparatus For 10/731,796 Dec. 9, 2003 Caching A Location Index In A Data Storage System Methods And Apparatus For 10/731,603 Dec. 9, 2003 Parsing A Content Address To Facilitate Selection Of A Physical Storage Location In A Data Storage System Methods And Apparatus For 10/731,845 Dec. 9, 2003 Generating A Content Address To Indicate Data Units Written To A Storage System Proximate In Time Methods And Apparatus For 10/762,044 Jan. 21, 2004 Modifying A Retention Period For Data In A Storage System Methods And Apparatus For 10/761,826 Jan. 21, 2004 Extending A Retention Period For Data In A Storage System Methods And Apparatus For 10/762,036 Jan. 21, 2004 Indirectly Identifying A Retention Period For Data In A Storage System Methods And Apparatus For 10/762,043 Jan. 21, 2004 Indirectly Identifying A Retention Period For Data In A Storage System Methods And Apparatus For 10/787,337 Feb. 26, 2004 Increasing Data Storage Capacity Methods And Apparatus For 10/787,670 Feb. 26, 2004 Storing Data In A Storage Environment Methods And Apparatus For 10/910,985 Aug. 4, 2004 Segregating A Content Addressable Computer System Methods And Apparatus For 10/911,330 Aug. 4, 2004 Accessing Content In A Virtual Pool On A Content Addressable Storage System Methods and Apparatus For 10/911,248 Aug. 4, 2004 Including Storage System Capability Information In An Access Request To A Content Addressable Storage System Methods And Apparatus For 10/911,247 Aug. 4, 2004 Tracking Content Storage In A Content Addressable Storage System Methods and Apparatus For 10/911,360 Aug. 4, 2004 Storing Information Identifying A Source Of A Content Unit Stored On A Content Addressable System Software System For 11/021,892 Dec. 23, 2004 Providing Storage System Functionality Software System For 11/022,022 Dec. 23, 2004 Providing Content Addressable Storage System Functionality Methods And Apparatus For 11/022,077 Dec. 23, 2004 Providing Data Retention Capability Via A Network Attached Storage Device Methods And Apparatus For 11/021,756 Dec. 23, 2004 Managing Storage In A Computer System Methods And Apparatus For 11/021,012 Dec. 23, 2004 Processing Access Requests In A Computer System Methods And Apparatus For 11/021,378 Dec. 23, 2004 Accessing Information In A Hierarchical File System Methods And Apparatus For 11/034,613 Jan. 12, 2005 Storing A Reflection On A Storage System Method And Apparatus For 11/034,737 Jan. 12, 2005 Modifying A Retention Period Methods And Apparatus For 11/034,732 Jan. 12, 2005 Managing Deletion of Data Methods And Apparatus For 11/107,520 Apr. 15, 2005 Managing The Storage Of Content Methods And Apparatus For 11/107,063 Apr. 15, 2005 Retrieval Of Content Units In A Time-Based Directory Structure Methods And Apparatus For 11/107,194 Apr. 15, 2005 Managing The Replication Of Content Methods And Apparatus For 11/165,104 Jun. 23, 2005 Managing the Storage Of Content In A File System Methods And Apparatus For 11/165,103 Jun. 23, 2005 Accessing Content Stored In A File System Methods And Apparatus For 11/165,102 Jun. 23, 2005 Storing Content In A File System Methods And Apparatus For 11/212,898 Aug. 26, 2005 Managing the Storage of Content Methods And Apparatus For 11/213,565 Aug. 26, 2005 Scheduling An Action on a Computer Methods And Apparatus For 11/213,233 Aug. 26, 2005 Deleting Content From A Storage System Method and Apparatus For 11/324,615 Jan. 3, 2006 Managing The Storage Of Content Method and Apparatus For 11/324,639 Jan. 3, 2006 Providing An Interface To A Storage System Methods And Apparatus For 11/324,533 Jan. 3, 2006 Managing A File System On A Content Addressable Storage System Methods And Apparatus For 11/324,637 Jan. 3, 2006 Creating A File System Methods And Apparatus For 11/324,726 Jan. 3, 2006 Mounting A File System Methods And Apparatus For 11/324,642 Jan. 3, 2006 Allowing Access To Content Methods And Apparatus For 11/324,727 Jan. 3, 2006 Implementing A File System That Stores Files On A Content Addressable Storage System Methods And Apparatus For 11/324,728 Jan. 3, 2006 Reconfiguring A Storage System Methods And Apparatus For 11/324,646 Jan. 3, 2006 Increasing The Storage Capacity Of A Storage System Methods And Apparatus For 11/324,644 Jan. 3, 2006 Accessing Content On A Storage System Methods And Apparatus For 11/392,969 Mar. 28, 2006 Transferring Content From A Storage System Methods And Apparatus For 11/391,654 Mar. 28, 2006 Requesting Content From A Storage System Methods And Apparatus For 11/392,981 Mar. 28, 2006 Transferring Content To Multiple Destinations Methods And Apparatus For 11/390,878 Mar. 28, 2006 Receiving Content From A Storage System At Multiple Servers Methods And Apparatus For 11/390,564 Mar. 28, 2006 Transferring Content From An Object Addressable Storage System Methods And Apparatus For 11/391,636 Mar. 28, 2006 Requesting Content From An Object Addressable Storage System Methods And Apparatus For 11/438,770 May 23, 2006 Conversion Of Content Methods And Apparatus For 11/439,025 May 23, 2006 Selecting A Data Format For A Content Unit Methods And Apparatus For 11/439,022 May 23, 2006 Accessing A Content Unit On A Storage System Methods And Apparatus For 11/438,817 May 23, 2006 Enabling Selection Of A Content Unit Data Format Methods And Apparatus For 11/474,658 Jun. 26, 2006 Accessing Content Methods And Apparatus For 11/474,846 Jun. 26, 2006 Providing Access To Content Methods And Apparatus For 11/474,655 Jun. 26, 2006 Retrieving Stored Content Methods And Apparatus For 11/474,661 Jun. 26, 2006 Accessing Content Through Multiple Nodes Methods And Apparatus For 11/474,719 Jun. 26, 2006 Receiving Content Methods And Apparatus For 11/474,749 Jun. 26, 2006 Processing Access Requests Methods And Apparatus For 11/474,802 Jun. 26, 2006 Providing Content Methods And Apparatus For 11/483,465 Jul. 10, 2006 Managing Content Methods And Apparatus For 11/483,799 Jul. 10, 2006 Moving Content Methods And Apparatus For 11/483,494 Jul. 10, 2006 Storing Content Methods And Apparatus For 11/519,374 Sep. 12, 2006 Caching Content In A Computer System Employing Object Addressable Storage Methods And Apparatus For 11/644,430 Dec. 22, 2006 Selection Of A Storage Location For A Content Unit Methods And Apparatus For 11/644,423 Dec. 22, 2006 Modifying An Object Identifier For A Content Unit Methods And Apparatus For 11/644,174 Dec. 22, 2006 Storing Content On A Storage System Methods And Apparatus For 11/644,857 Dec. 22, 2006 Increasing The Storage Capacity Of A Zone Of A Storage System Methods And Apparatus For 11/644,428 Dec. 22, 2006 Selecting A Storage Zone For A Content Unit

(51) While the invention has been disclosed in connection with preferred embodiments shown and described in detail, their modifications and improvements thereon will become readily apparent to those skilled in the art. Accordingly, the spirit and scope of the present invention should be limited only by the following claims.