Method and system for caching metadata of a storage system

A management server maintains a set of metadata describing a storage structure of a storage server. In response to a change of the storage structure, the management server automatically updates the set of metadata. The management server also manages information indicating what portion of the set of metadata is cached locally at a storage management client application. If that portion of the set of metadata is updated in response to the change of the storage structure, the management server sends information to update the metadata cached locally at the storage management client application so that the cached metadata is consistent with the set of metadata at the management server. By caching data at the storage management client application and at the network storage management server, the present invention advantageously avoids sending unnecessary requests to the storage server, thereby reducing network latency.

FIELD OF THE INVENTION

At least one embodiment of the present invention pertains to storage systems, and more particularly, to managing storage systems.

BACKGROUND

Various forms of network-based storage systems are known today. These forms include network attached storage (NAS), storage area networks (SANs), and others. Network storage systems are commonly used for a variety of purposes, such as providing multiple users with access to shared data, backing up critical data (e.g., by data mirroring), etc.

A network-based storage system typically includes at least one storage server, which is a processing system configured to store and retrieve data on behalf of one or more client processing systems (“clients”). In the context of NAS, a storage server may be a file server, which is sometimes called a “filer”. A filer operates on behalf of one or more clients to store and manage shared files. The files may be stored in a storage subsystem that includes one or more arrays of mass storage devices, such as magnetic or optical disks or tapes, by using RAID (Redundant Array of Inexpensive Disks). Hence, the mass storage devices in each array may be organized into one or more separate RAID groups.

In a SAN context, a storage server provides clients with block-level access to stored data, rather than file-level access. Some storage servers are capable of providing clients with both file-level access and block-level access, such as certain Filers made by Network Appliance, Inc. (NetApp®) of Sunnyvale, Calif.

In file servers, data is commonly stored in logical containers called volumes, which may be identical with, or subsets of, aggregates. An “aggregate” is a logical container for a pool of storage, combining one or more physical mass storage devices (e.g., disks) or parts thereof into a single logical storage object, which contains or provides storage for one or more other logical storage objects at a higher level of abstraction (e.g., volumes). A “volume” is a set of stored data associated with a collection of mass storage devices, such as disks, which obtains its storage from (i.e., is contained within, and may be coextensive with) an aggregate, and which is managed as an independent administrative unit, such as a complete file system. A “file system” is an independently managed, self-contained, hierarchal set of data units (e.g., files, blocks or LUNs). Although a volume or file system (as those terms are used herein) may store data in the form of files, that is not always the case. That is, a volume or file system may store data in the form of other units, such as blocks or LUNs.

A storage server has the capability to create a persistent, point-in-time image (PPI) of a dataset, such as a volume or a LUN, including its metadata. This capability allows the exact state of the dataset to be restored from the PPI in the event of, for example, data corruption or accidental data deletion. The ability to restore data from a PPI provides administrators with a mechanism to revert the state of their data to a known previous point in time as captured by the PPI. An example of an implementation of a PPI is a Snapshot™ generated by SnapDrive™ or SnapManager® for Microsoft® Exchange software, both made by Network Appliance, Inc. of Sunnyvale, Calif.

A storage server may be managed by a network storage administrator (also called “administrative users” or simply “administrators”) by using a storage management console on a network, which may be a computer system that runs storage management software application specifically designed to manage a distributed storage infrastructure. Through the storage management console, the administrator may submit storage management commands to be performed by the storage server, such as creating a volume. A storage management command needs to be checked against the metadata of the storage server to determine whether the command may be performed by the storage server. A command cannot be performed if it violates data and/or structural integrity of the storage server's storage system.

Metadata of a storage server describes a storage structure of the storage server's storage system(s). Particularly, metadata of a storage server includes data identifying logical storage objects of the storage server and relationships among these logical storage objects. A logical storage object (hereinafter “storage object”) is a logical storage unit of a storage server (e.g., a volume, a LUN, a PPI). An example of relationship between two storage objects is a parent-child relationship in which one storage object contains the other storage object (e.g., directory and file, or volume and directory, etc.)

In existing implementations, a storage management application usually sends a storage management command to the storage server. If the command violates the storage server's data and/or structural integrity, the storage server sends an error message to the storage management software application. This, in turn, introduces both unnecessary network latency and unnecessary network traffic.

SUMMARY OF THE INVENTION

The present invention includes a method and system for caching metadata of a storage system. The method includes maintaining a set of metadata describing a storage structure of a storage server at a network storage management server. The method further includes automatically updating the set of metadata at the network storage management server in response to a change of the storage structure and the step of sending from the network storage management server at least a portion of the set of metadata to a storage management client application to update metadata cached locally at the storage management client application. By caching data at the storage management client application and at the network storage management server, the present invention advantageously avoids sending unnecessary requests to the storage server, thereby reducing network latency.

Other aspects of the invention will be apparent from the accompanying figures and from the detailed description which follows.

DETAILED DESCRIPTION

A method and apparatus for caching metadata of a storage system are described. According to the technique introduced here, a portion of a set of metadata describing a storage structure of a storage system is cached locally at a storage management client application at each client system. In response to a command initiated by a user or a process, the storage management client application determines, based on the locally cached metadata, whether the command violates data and/or structural integrity of the storage system. If there is a violation, the storage management client application does not send the command to the storage system, but returns an error message to the initiated command. A copy of the set of metadata is maintained at a Network Storage Management Server (NSMS). In response to a change of the storage structure of the storage system, the NSMS updates the copy of the set of metadata. In addition, the NSMS determines the storage management client application(s) whose locally cached metadata needs to be updated. The NSMS sends relevant portion of the set of metadata to each of the identified storage management client application to update the metadata cached locally at the client system.

References in this specification to “an embodiment”, “one embodiment”, or the like, mean that the particular feature, structure or characteristic being described is included in at least one embodiment of the present invention. Occurrences of such phrases in this specification do not necessarily all refer to the same embodiment.

FIG. 1illustrates a network environment in which the invention can be implemented. InFIG. 1, a number of storage servers2are each coupled locally to a separate storage subsystem4, each of which includes multiple mass storage devices. The storage servers2are also coupled through an interconnect3to a number of clients1. Each storage subsystem4is managed by its corresponding storage server2.

Each of the clients1can be a computer system such as the one shown inFIG. 9. Such a computer system includes a processor, a memory, adapters, etc. In one embodiment, each of the clients1may send read or write requests directed to data stored in or to be stored in the corresponding storage subsystem4.

Each of the clients1may execute a storage management client application6. In one embodiment, the storage management client application6submits a storage management command from client1to a storage server2. The storage management command may be, for example, a command to create a PPI of a volume on the storage server2. The command may be initiated at the client1, or may be initiated by a user who is remotely connected to the client1.

In one embodiment, client1maintains a virtual storage unit8. As used herein, a storage unit refers to a volume, a file system, or a directory, etc. Although data contained and organized by a virtual storage unit8is not stored on the client1that hosts the virtual storage unit8, the virtual storage unit8appears to a user or software process of the client1as if the data of the virtual storage unit8was stored on the client1. The storage management application6maintains configuration information of the virtual storage unit8. Such configuration information includes the mapping between the virtual storage unit8and the storage object of a storage server2which stores the data for the virtual storage unit8. For example, the virtual storage unit8may be a file system by the name /mnt/oracle. Configuration information may include: name of the device local to client1, on which /mnt/oracle is mounted (e.g., /dev/sdc); name of the LUN (e.g., /vol/oraclvol/oracle_lun) which resides on a storage server and which is mapped to /dev/sdc; name of the volume (e.g., /vol/oracle) on which the

In one embodiment, a user may submit a request to access data of the virtual storage unit8(such as a request to read a file) or a request to modify the virtual storage unit8(such as a request to create a directory). In response to the request, the storage management client application6determines the storage object and the storage server2which maintains the data of the virtual storage unit8. A person of ordinary skill in the art would understand that the request may also be initiated by a software process, such as a pre-scheduled storage management task (not shown inFIG. 1). After the storage object and the storage server2are determined, the storage management client application6converts the request into a storage server specific command or an Application Programming Interface (API) call. According to an embodiment of the present invention, before the storage management client application6submits the command or an API call to the storage server2, the storage management client application6checks whether it has metadata regarding the storage object of the storage server2cached locally, for example, in cache9of the client1. If storage management client application6does not have the metadata, the storage management client application6requests such metadata from the NSMS5. Then, the storage management client application6receives the metadata from the NSMS5and stores it in cache9of the client1. Before the storage management client application6submits the command or API call to the storage server2, the storage management client application6determines, based on the locally cached metadata in cache9, whether the operation to be accomplished by the command or API call violates data and/or structural integrity of the storage server's storage system. If the violation is detected, the storage management client application6aborts the operation and reports an error. Otherwise, the command or API call is submitted to the storage server2. This advantageously avoids submitting multiple commands to storage server2. In one embodiment, cache9is a cache memory or a part of a main memory (such as memory22shown inFIG. 9). A person of ordinary skill in the art would understand that cache9may also be implemented in a mass storage device (such as mass storage26shown inFIG. 9).

Still referring toFIG. 1, Network Storage Management Server (NSMS)5is also connected to the interconnect3. The NSMS5is a computer system, such as the computer system shown inFIG. 9. The NSMS5has a processor, a memory, adapters, etc. According to one embodiment of the present invention, the NSMS5is initialized to maintain a copy of a set of metadata describing a storage structure of each of the storage servers2. In response to any change of the storage structure of each of the storage servers2, the NSMS5updates the copy of the set of metadata after receiving periodic updates from the storage servers2, as will be described in more detail herein. Further, the NSMS5identifies storage management client application(s)6whose locally cached metadata needs to be updated. Then, the NSMS5sends a relevant portion of the set of metadata to the identified storage management client application(s)6to update the metadata cached at the corresponding storage management client application6.

The NSMS5also executes a storage management console7. The storage management console7is an application configured to provide an interface allowing a user (such as an administrator of a virtual storage unit8) or a software process to control a storage management client application6. Such an interface may be either a user interface (a Graphical User Interface, for example) or an API.

The NSMS5and each of the clients1may be, for example, a conventional personal computer (PC), server class computer, workstation, or the like. Each of the clients1may execute an operating system such as Windows®, UNIX®, etc.

Storage server2may be, for example, a file server used in a NAS environment (a “filer”), a block-based storage server such as used in a storage area network (SAN), or other type of storage server. In a NAS implementation, the interconnect3may be essentially any type of computer network, such as a local area network (LAN), a wide area network (WAN), metropolitan area network (MAN) or the Internet, and may implement the Internet Protocol (IP). In a SAN implementation, the interconnect3may be, for example, a Fibre Channel switching fabric which implements the Fibre Channel Protocol (FCP).

The mass storage devices in each storage subsystem4may be, for example, conventional magnetic disks, optical disks such as CD-ROM or DVD based storage, magneto-optical (MO) storage, or any other type of non-volatile storage devices suitable for storing large quantities of data. The storage devices in each storage subsystem4can be organized as a Redundant Array of Inexpensive Disks (RAID), in which case the corresponding storage server2accesses the storage subsystem4using an appropriate RAID protocol, such as, for example, RAID-4, RAID-5, RAID-DP, or any other RAID protocol.

Storage servers may have distributed architectures, to facilitate clustering of storage nodes. Clustering facilitates scaling of performance and storage capacity. For example, rather than being implemented in a single box, any one or more of the storage servers2may include a separate N—(“network”) module and D—(disk) module, which are contained within separate housings and communicate with each other via some type of switching fabric or other communication medium. An N-module is an element that acts as a front-end of a storage server, exporting a file service abstraction to clients. A D-module manages the underlying storage. Each D-module typically manages a separate set of disks. Storage servers which implement the Data ONTAP® GX operating system from NetApp can have this type of distributed architecture.

FIG. 2Aillustrates an example of architecture of the Network Storage Management Server5(shown inFIG. 1) according to an embodiment of the present invention. As shown inFIG. 2A, the NSMS5includes a metadata management module201, a cache management module202, an access control module203, request queues204, data structures, such as metadata data structure205, a lock map206, and cache management data structure207. The NSMS5also executes a storage management console7as illustrated inFIG. 1.

Metadata data structure205stores a copy of a set of metadata describing a storage structure of each of the storage servers2. In an embodiment of the present invention, metadata describing a storage structure of a storage server2includes data identifying storage objects maintained by the storage server and relationships among these storage objects. Examples of storage object include a volume, a Logical Unit Number (LUN), and a Persistent Point-in-time Image (PPI), although other objects can be used. An example of a relationship between two storage objects is a parent-child relationship, in which one storage object contains the other storage object. A change of a storage structure of a storage server may include an addition of a storage object as a result of the creation of the storage object, a removal of an existing storage object, or a change of one of the attributes of an existing storage object. Examples of an attribute of a storage object include a name of the storage object, free storage space available on the storage object, etc.

The metadata management module201manages the set of metadata stored in metadata data structure205. The metadata management module201monitors each of the storage servers2to determine whether there is any change in the storage structure. In another embodiment, each storage server2can inform the metadata management module201of any storage structure change that occurred. In response to any storage structure change, the corresponding storage server2sends the changed metadata to the metadata management module201to update the copy of the set of metadata stored in metadata data structure205.

Metadata management module201can be implemented as software, firmware, specially designed hardware, or any combination thereof. Metadata data structure205, may be any data structure that organizes and stores data, such as a database table, a file, etc.

The NSMS5also executes a cache management module202. The cache management module202manages a data structure, such as cache management data structure207. In an embodiment of the present invention, each storage management client application6(as shown inFIG. 1) caches a portion of a set of metadata describing the storage structure of a storage server2.

Cache management data structure207organizes and stores data identifying which portion of the set of metadata is cached by each storage management client application6. In response to a change of the copy of the set of metadata stored in metadata data structure205, the cache management module202determines, based on data stored in cache management data structure207, the storage management client application(s)6whose locally cached metadata needs to be updated. Then, the cache management module202sends updated metadata to each of the identified storage management client application(s)6to update the metadata cached locally at the corresponding storage management client application6. Cache management module202can be implemented as software, firmware, specially designed hardware, or any combination thereof. The cache management data structure207, may be any data structure that organizes and stores data, such as a database table, a file, etc.

The NSMS5further executes an access control module203. The access control module203controls access to storage objects of each storage server2. For example, the access control module203determines whether an access request directed to a storage object of a storage server2should be allowed based on data organized and stored in lock map206. Such an access request may be, for example, sent from a storage management client application6. Lock map206maintains lock information for each storage object of a storage server2. When a storage object is being accessed in response to a request sent from a storage management client application6, the storage object is locked so that another access request may need to wait until the current request is being processed. In one embodiment, if the access control module203determines that a request cannot be allowed at the moment, the access control module203puts the request in one of the request queues204. Access control module203can be implemented as software, firmware, specially designed hardware, or any combination thereof.

A user or a software process may initiate a storage management request, from a storage management console7, to a storage management client application6. In one embodiment, if the request is directed to a storage object of a storage server2, the storage management console7may determine whether the storage object of the storage server2is locked. However, if the request is directed to a virtual storage unit8of a client1, the storage management console7forwards the request to the storage management client application6on the corresponding client1. Because the storage management client application6has the configuration information of the virtual storage unit8, it is able to determine the storage object and the storage server2which maintains the data of the virtual storage unit8. The storage management client application6then sends the identities of the storage object and the storage server2back to the access control module203. The access control module203, in turn, determines whether the storage object on the particular storage server2is locked. The lock map206may be any data structure that organizes and stores data, such as a database table, a file, etc.

A person of ordinary skill in the art would understand that data or part of the data stored in metadata data structure205, lock map206and/or cache management data structure207may be resident in a main memory (such as memory22shown inFIG. 9) or a cache memory for faster access.

FIG. 2Billustrates an operating system of a storage server2. As shown, the operating system can include several modules, or layers. These modules or layers include a file system manager31, a network protocol layer32, a network access layer33, a storage access layer34and a storage driver layer35.

The file system manager31is an application-level programmatic entity which imposes a structure (e.g. hierarchical) on volumes, files, directories and/or other data containers stored and/or managed by a storage server2, which services read/write requests from clients1of the storage server2. In one embodiment, the file system manager31organizes and manages metadata describing a storage structure of the storage server2. In response to a storage structure change, the file system manager31sends updated metadata to the NSMS5. Alternatively, the NSMS5may periodically send a request or an API call to the file system manager31to request updated metadata. An example of a file system manager employed by the present invention is WAFL® file system that is part of the Data ONTAP® storage operating system, both provided by Network Appliance, Sunnyvale, Calif. A person of ordinary skill in the art would understand that other file systems can be used in accordance with the inventive principles described herein.

Logically, under the file system manager31, the operating system also includes a network protocol layer32and an associated network access layer33, to allow the storage server2to communicate over a network (e.g., with clients1). The network protocol layer32implements various protocols, such as NFS, CIFS, HTTP, SNMP, and TCP/IP. The network access layer33includes one or more drivers, which implement one or more protocols to communicate over the interconnect3, such as the Ethernet or Fibre Channel. Also logically under the file system manager31, the operating system includes a storage access layer34and an associated storage driver layer35, to allow the storage server2to communicate with the storage subsystem4. The storage access layer34implements a storage redundancy protocol, such as, for example, RAID-4 or RAID-5. It should be understood that other types and levels of RAID implementations may be used in accordance with the inventive principles described herein. The storage driver layer35implements a lower-level storage device access protocol, such as Fibre Channel or SCSI. Reference numeral37inFIG. 3shows the data access path through the operating system, associated with servicing read and write requests from clients1.

FIG. 3illustrates an example of an embodiment of metadata data structure205shown inFIG. 2. As shown, a set of metadata describing a storage structure of a storage server2may be stored in a table. An entry in the table may include a storage object ID field301, a storage object name field302, a free space available field303and a parent object ID field304. The storage object ID field301stores identification of a storage object. The storage object name field302stores a name of the storage object. The free space available field303stores the amount of free space currently available on the storage object. The parent object ID field304stores a parent object ID.

FIG. 4illustrates an example of an embodiment of lock map206shown inFIG. 2. As shown, an exemplary entry of lock map206includes the following fields: a storage object ID field401, an exclusive lock field402and a shared lock field403. Fields402and403indicate whether a particular storage object is being accessed in an exclusive mode (i.e., no other access requests can access the storage object) or in a shared mode (i.e., the storage object is allowed to be accessed simultaneously or concurrently by another access request which does not require exclusively lock the same storage object.). In one embodiment, when exclusive lock field402is set as “1”, it indicates that the storage object is locked exclusively. In one embodiment, when a storage object is being accessed in a shared mode, the corresponding shared field403is set as “1” meaning the storage object is currently locked in a shared mode. Of course, the setting of a lock could be represented using other values. A person of ordinary skill in the art would understand that lock map206and metadata data structure205may be organized and stored in one data structure, such as a database table.

FIG. 5illustrates an example of an embodiment of cache management data structure207shown inFIG. 2. As shown, an exemplary entry of cache management data structure207may have a storage management client application ID field501and a storage object ID field502. The storage management client application ID field501identifies a storage management client application. The storage object ID field502identifies a storage object. Each entry in cache management data structure207represents that the metadata cached locally at the corresponding storage management client application6includes information regarding the corresponding storage object. For example, as shown inFIG. 5, metadata regarding the storage objects identified with IDs1,2and30are currently cached by the storage management client application6with ID “1”.

FIG. 6Ais a flow diagram illustrating a process of caching metadata locally to a storage management client application6. In one embodiment, the metadata is cached in cache9of the client1, on which the storage management client application6is executed. At block601, the storage management client application6receives a request to access a storage object on a storage server2. The request may be, for example, originated from a user at the storage management console7on the NSMS5.

At block602, the storage management client application6determines whether the local cache9stores metadata regarding the storage object. Here, metadata regarding a storage object includes metadata of the parents and children of the storage object. For example, as shown inFIG. 3, metadata regarding a storage object “Volume_Data” includes metadata of the storage object “Volume_Data” as well as metadata of the storage object “Server_Engineer_1” and metadata of the storage object “LUN_Oracle”.

If the local cache9does not store metadata regarding the storage object, then at block603, the storage management client application6requests metadata regarding the storage object from the NSMS5. At block604, the storage management client application6then caches in cache9metadata received from NSMS5.

Note that after the NSMS5sends the metadata regarding the storage object to the storage management client application6, NSMS5updates the cache management data structure207to record those storage objects which metadata is sent to the storage management client application6for caching.

FIG. 6Bis a flow diagram illustrating a process of updating metadata cached locally at the storage management client application6. At block611, NSMS5(shown inFIG. 1) is initialized to store a copy of a set of metadata describing a storage structure of a storage server2(shown inFIG. 1). The NSMS5may be initialized when a storage server2registers with the NSMS5. The registration may be done manually by a user (e.g., a network administrator) or automatically by a software process running at the storage server (the software process is not shown inFIGS. 1-9). For example, the software process may be a program which automatically detects an NSMS on a network. Upon discovering an NSMS5, the software process registers the storage server2with the NSMS5. The set of metadata may be, for example, stored in metadata blocks of the storage server2. In one embodiment, the metadata is organized and managed by the file system manager layer31of storage server's operating system. After the registration, the storage server2transfers a set of metadata to the NSMS5. In one embodiment of the present invention, more than one storage server2may register with the NSMS5. Thus, more than one sets of metadata may be maintained and stored at the NSMS5.

At block612, the NSMS5updates the copy of the set of metadata if the storage structure of the corresponding storage server2is changed. Such change may include, for example, an addition of a storage object as a result of the creation of the storage object, a removal of an existing storage object, or a change of one of the attributes of an existing storage object. Attributes of a storage object may include the name of the storage object, free storage space available on the storage object, etc. For example, if a volume is created on a storage server, the newly created volume's storage object ID, name, free space available on the volume, and parent storage object's ID (the storage server's ID) are sent by the storage server2to the NSMS5. A new entry is created in the metadata data structure205to reflect the newly created volume. On the other hand, if a volume is deleted, then information regarding the deletion of the volume is sent by the storage server2to the NSMS5. The corresponding entry representing the deleted volume in metadata data structure205is removed to reflect the deletion of the volume.

At block613, the cache management module202of the NSMS5looks up the cache management data structure207to determine the storage management client application(s)6whose locally cached metadata needs to be updated as a result of the update of the copy of the set of metadata at the NSMS5. First, the cache management module202determines the ID of the storage object that has been added, removed or otherwise modified during the update. Then, the cache management module202looks up the cache management data structure207to find the storage management client application ID or IDs that are mapped to the storage object ID.

At block614, it is determined whether such storage management client application(s)6is found. If no such storage management client application6is found, the process ends with respect to this particular transaction. Otherwise, if the application6is found, at block615, the cache management module202sends information to the corresponding storage management client application(s)6to update the locally cached metadata respectively. For example, if a volume is deleted, a message indicating that the volume is deleted is sent to a corresponding storage management client application6for updating the locally cached metadata. The process ends at block616.

Referring now toFIG. 8, it illustrates an event diagram of the steps performed by NSMS5and client1. At block801, the NSMS5is initialized to maintain a copy of a set of metadata describing the storage structure of a storage server2. The NSMS5may be initialized according to the process illustrated in block611ofFIG. 6B.

At block802, a user logs into a storage management console7, to connect to a storage management client application6. In one embodiment, as the user logs in, the user specifies which storage management client application6the user wants to connect to. Alternatively, the user may log into the storage management console7first and then specify the client application6he wants to connect to.

At block803, the storage management console7on the NSMS5receives a storage management request850from the user. The storage management request850may be, for example, a command directed to a virtual storage unit8maintained on a client1. The storage management request850may also be, for example, a command directly directed to a storage object of a storage server2.

At block804, the NSMS5sends the request850to the storage management client application6.

At block805, the storage management client application6receives the request850.

At block806, the storage management client application6determines the storage object and storage server2to which the request850is directed. For example, the storage management client application6may access the configuration information of the virtual storage unit8to determine which storage object on which storage server is storing the data of the virtual storage unit8,

At block807, the storage management client application6determines whether metadata regarding the storage object of the storage server2is cached locally in cache9. If not, the storage management client application6requests such metadata from the NSMS5according to the process described inFIG. 6A.

At block808, based on the locally cached metadata, the storage management client application6determines whether the request850should be submitted to the storage server2. For example, assuming the locally cached metadata indicates that there is already a volume named “user” in the storage server “engineer_a”, a request to create a new volume named “user” on the storage server “engineer_a” cannot succeed because of a name conflict. Thus, if the command is submitted to the storage server2, it will be rejected by the storage server2, which unnecessarily consumes the network bandwidth and the storage server's processing resources. To avoid the above problem, at block809, if the command is allowable according to the determination made at block807, the storage management client application6sends, at block809, information851including the identities of the storage object and the storage server2to the NSMS5. Application6then awaits for a response. Otherwise, if the command is not allowable, at block815, the storage management client application6sends an error message to inform the user of the failure. Thus, by caching metadata of storage objects at client1and at NSMS5the present invention advantageously avoids sending unnecessary requests to storage server2, thereby reducing network latency.

However, if the storage management request850is directed to a storage object of a storage server2, the above process in blocks804-809may be omitted because the storage object and the storage server may be determined directly from information stored in the request850. In this case, the NSMS5may determine, based on data stored in metadata data structure205, whether the request850will fail because it violates the data/structure integrity of the storage server2. At block810, the access control module203determines whether the request850can be submitted to the storage server2based on data stored in lock map206.

Referring now toFIG. 7, it illustrates the steps performed by access control module203to determine whether the request850can be submitted to the storage server. The request may be, for example, to create a PPI for a volume “user” on a storage server “engineer_a”.

At block702, the access control module203looks up lock map206to determine whether the storage object is locked as “exclusive”. If the storage object is locked as “exclusive”, the request is denied. If the storage object is not locked as “exclusive”, the access control module203determines, at block703, whether the storage object is locked as “shared”. If the storage object is locked as “shared”, the access control module203determines, at block704, whether the request needs an exclusive access. If the request needs an exclusive access, the request is denied at block706. If the request does not need exclusive access, the request is allowed at block705. In one embodiment, if a request is allowed, a message is sent back to inform the storage management console7or the storage management client application6that it may submit the request to the storage server2. If a request is denied, a message is sent back to inform the storage management console7or the storage management client application6that it may not submit the request to the storage server2at the moment. The storage management console7or the storage management client application6may resubmit the request at a later time. Alternatively, if a request is denied, the access control module203puts the request in a request queue204. The access control module203then sends a message to inform the corresponding storage management console7or the storage management client application6that the request is pending and a new message will be sent to it as soon as the request may be allowed. If, however, the storage object is not locked as “shared”, as determined at block703, the request is allowed at block705.

Referring again toFIG. 8, the access control module203then sends a response852back to the storage management client application6. At block811, the storage management client application6receives the response852from the NSMS5. If the message indicates that the request850is allowed, the storage management client application6submits the request850, at block812, to the storage server2. Also, at block812, the storage management client application6sends a message853to inform the NSMS5that the request has been sent to the storage server2.

At block813, the NSMS5receives the confirmation message853and locks the storage object. Based on the type of the request, the storage object is locked either as “exclusive” or as “shared”. For example, an operation of deleting a PPI requires exclusive access to the PPI. An operation to read the data of the PPI requires shared access.

At block814, after the request is performed (for example, a volume is created), the storage management client application6sends a message854to inform the NSMS5so that it may unlock any storage object locked for the request.

Otherwise, at block811, if the response is not an authorization, the process loops back to block809, where the storage management client application6may resend the information and waits for another response.

Thus, embodiments of the present invention first submit requests to NSMS5to determine whether a request to server2can be submitted. This avoids sending multiple requests to storage server2.

FIG. 9is a high-level block diagram showing an example of the components of the client and NSMS5shown inFIG. 1.

Certain standard and well-known components which are not germane to the present invention are not shown. The system shown inFIG. 9includes one or more processors21coupled to a bus system23.

The bus system23inFIG. 9is an abstraction that represents any one or more separate physical buses and/or point-to-point connections, connected by appropriate bridges, adapters and/or controllers. The bus system23, therefore, may include, for example, a system bus, a Peripheral Component Interconnect (PCI) bus, a HyperTransport or industry standard architecture (ISA) bus, a small computer system interface (SCSI) bus, a universal serial bus (USB), or an Institute of Electrical and Electronics Engineers (IEEE) standard 1394 bus (sometimes referred to as “Firewire”). The processors21are the central processing units (CPUs) of the processing system and, thus, control the overall operation of the processing system. In certain embodiments, the processors21accomplish this by executing software stored in memory22. A processor21may be, or may include, one or more programmable general-purpose or special-purpose microprocessors, digital signal processors (DSPs), programmable controllers, application specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), or the like, or a combination of such devices.

The processing system also includes memory22coupled to the bus system43. The memory22represents any form of random access memory (RAM), read-only memory (ROM), flash memory, or a combination thereof. Memory22stores, among other things, the operating system24of processing system.

Also connected to the processors21through the bus system23are a mass storage device26, a storage adapter27, and a network adapter28. Mass storage device26may be or include any conventional medium for storing large quantities of data in a non-volatile manner, such as one or more disks. The storage adapter27allows the processing system to access a storage subsystem and may be, for example, a Fibre Channel adapter or a SCSI adapter. The network adapter28provides the processing system with the ability to communicate with remote devices over a network and may be, for example, an Ethernet adapter or a Fibre Channel adapter. Memory22and mass storage device26store software instructions and/or data, which may include instructions and/or data used to implement the techniques introduced here.

Thus, a method and apparatus for caching metadata of a storage system have been described.

Software to implement the technique introduced here may be stored on a machine-readable medium. A “machine-accessible medium”, as the term is used herein, includes any mechanism that provides (i.e., stores and/or transmits) information in a form accessible by a machine (e.g., a computer, network device, personal digital assistant (PDA), manufacturing tool, any device with a set of one or more processors, etc.). For example, a machine-accessible medium includes recordable/non-recordable media (e.g., read-only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; etc.), etc.

“Logic”, as is used herein, may include, for example, software, hardware and/or combinations of hardware and software.