System for managing asset access in a distributed storage system

[0002] 1. Field of the Invention

[0003] The present invention relates to managing access to assets in distributed data storage systems such as file systems and databases.

[0004] 2. Description of the Related Art

[0005] Distributed file systems are used to provide data sharing in distributed computer systems. Such systems centralize data storage, which improves the scalability and manageability of data access control. Moreover, centralized data storage also facilitates, among other things, easier storage device replacement and data backups, as compared to systems in which data storage is fragmented among local storage devices of many computers. It is to be understood that while, for disclosure purposes, the present discussion focuses on file systems, the principles set forth herein apply equally to other distributed data storage systems, such as distributed database systems.

[0006] To synchronize data access such that users share consistent views of shared data, requests from users to read and write data typically are sent to a central file server. The file server then manages access to the data using “locks” to ensure, e.g., that one user is not updating shared data by writing to it while another user might read an out-of-date version of the same data. In distributed systems, locks ordinarily are preemptible, in that the server can demand a lock previously provided by the server to one user to enable the user to access a file, and then give the lock to a second user. Unfortunately, requiring a central server to actively manage all data access degrades performance as compared to accessing a local data cache, since the server essentially represents a bottleneck.

[0007] As recognized by the present invention, while a central server can be used to manage synchronized access and coherent views of data, to optimize system performance the server should not be used as a target for all read and write requests. Stated differently, the present invention recognizes that it is desirable to provide local storage system semantics in a distributed environment, wherein communications with a server is minimized where possible. In this way, the speed, ease, and efficiency of accessing assets in a distributed storage network can approach that of accessing data in a local cache. Furthermore, the present invention understands that any asset locking scheme preferably be amenable to simplification, to further improve system performance.

[0008] A general purpose computer is programmed according to the inventive steps herein to manage access to assets in a distributed storage system. The invention can also be embodied as an article of manufacture—a machine component—that is used by a digital processing apparatus and which tangibly embodies a program of instructions that are executable by the digital processing apparatus to execute the present logic. This invention is realized in a critical machine component that causes a digital processing apparatus to perform the inventive method steps herein.

[0009] The invention can be implemented by a computer system including at least one general purpose client computer, at least one general purpose server computer, and a distributed data storage system accessible to at least the client computer. The system also includes logic that can be executed by the client computer for undertaking method acts to manage access to assets in the storage system. The method acts undertaken by the client computer include sending a request for a first semi-preemptible access lock from the client computer to the server computer. The access lock can be thought of as a distributed lock that encapsulates local open instances protected by non-preemptible local locks, also referred to as file locks.

[0010] Also, the method acts include receiving the first access lock from the server computer, it being understood that the access lock pertains to at least one asset in the storage system. The asset is characterized by either an open state or a closed state. A demand can be subsequently received from the server computer for the first access lock, and the method includes selectively not relinquishing the first access lock if the open state exists for the asset, and otherwise relinquishing the first access lock.

[0011] The preferred method undertaken by the client computer includes, if an open state exists for the asset, attempting to downgrade incompatible locks held by the client computer, with the incompatible locks being characterized as being incompatible with the first access lock. The first access lock is not relinquished if any incompatible lock cannot be downgraded.

[0012] In another aspect, a computer system includes at least one general purpose client computer, at least one general purpose server computer, and a distributed data storage system accessible to at least the client computer. The system also includes logic that can be executed by the server computer for undertaking method acts to manage access to assets in the storage system. The method acts undertaken by the server computer include receiving a request for a first semi-preemptible access lock from a first client computer, and determining at least whether the first lock is compatible with a second semi-preemptible lock associated with a second client computer. Also, the logic includes granting the request if the first lock is compatible with the second lock, and otherwise demanding the second lock.

[0013] In still another aspect, a computer-implemented method for managing access among plural client computers to assets in a distributed data storage system associated with at least one server computer includes issuing semi-preemptible access locks to client computers. In accordance with present principles, the semi-preemptible access locks are conditions precedent for the grant of a file lock to open a file. The semi-preemptible access locks are relinquished upon demand of the server computer when no associated file lock is invoked.

[0014] The details of the present invention, both as to its structure and operation, can best be understood in reference to the accompanying drawings, in which like reference numerals refer to like parts, and in which:

[0015] FIG. 1 is a schematic diagram showing the system of the present invention;

[0016] FIG. 2 is a table showing lock semantics;

[0017] FIG. 3 is a table showing lock compatibilities for an exemplary locking scheme;

[0018] FIG. 4 is a schematic representation of the legal upgrades and downgrades between locks;

[0019] FIG. 5 is a flow chart showing the logic executed by the server computer; and

[0020] FIG. 6 is a flow chart showing the logic executed by the client computer for processing a demand from the server.

[0021] Referring initially to FIG. 1, a system is shown, generally designated 10, for managing data access in a distributed data storage system, such as a storage area network (SAN) having associated client computers and at least one server computer. As shown, the system 10 can include a cluster of server computers, and the network can include plural storage disks and tapes and other storage devices. One or more of the disks can be “local” to a client computer, i.e., the client computer manages one or more disks as though the disks were local to the client computer.

[0022] In one intended embodiment, the computers of the present invention may be personal computers made by International Business Machines Corporation (IBM) of Armonk, N.Y., or the computers may be any computer, including computers sold under trademarks such as AS400, with accompanying IBM Network Stations. Or, the computers may be Unix computers, or OS/2 servers, or Windows NT servers, or IBM workstations or IBM laptop computers.

[0023] The flow charts herein illustrate the structure of the logic executed by the computers of the present invention as embodied in computer program software. Those skilled in the art will appreciate that the flow charts illustrate the structures of logic elements, such as computer program code elements or electronic logic circuits, that function according to this invention. Manifestly, the invention is practiced in its essential embodiment by a machine component that renders the logic elements in a form that instructs a digital processing apparatus (that is, a computer) to perform a sequence of function steps corresponding to those shown.

[0024] In other words, the flow charts may be embodied in a computer program that is executed by a processor within the computers as a series of computer-executable instructions. These instructions may reside, for example, in a program storage device 12 of the computers. The program storage device 12 may be RAM of the computers, or a magnetic or optical disk or diskette, DASD array, magnetic tape, electronic read-only memory, or other appropriate data storage device. In an illustrative embodiment of the invention, the computer-executable instructions may be lines of compiled C⁺⁺ compatible code.

[0025] To better understand the flow charts described below that illustrate the present invention, reference is first made to FIGS. 2-4. As a preferred but non-limiting example of the types of semi-preemptible access locks that can be used in the present invention, attention is now directed to FIG. 2, which shows a table 14 of locks and lock semantics. It is to be understood that a semi-preemptible access lock of the present invention permits predefined open accesses to assets in the data storage system as long as the semi-preemptible access lock is held by a client computer. That is, to access an asset a client computer first obtains a semi-preemptible access lock, and then, as further described below, the client computer can permit processes to obtain file locks as required to instantiate actual open instances. Once an actual open instance is closed and the file lock relinquished, the client computer nonetheless retains the semi-preemptible access lock to support subsequent open instances until such time as the semi-preemptible access lock is relinquished in accordance with the disclosure below.

[0026] As shown, six locks, respectively named “metadata”, “read”, “shared”, “write”, “update”, and “exclusive” can be provided from which a client computer can select, depending on the type of access to an asset that is desired by the client computer and the types of other concurrent open instances of the asset the client computer is willing to accept.

[0027] Accordingly, as indicated in the third column of the table 14, the “M” semi-preemptible access lock can be used to access metadata of an asset under the lock, and when the “M” lock is used another client computer concurrently can access the same asset for any other type of open instance, i.e., READ, METADATA, and WRITE. Furthermore, the “R” lock can be used to obtain read accesses of an asset, and when the “R” lock is used another client computer concurrently can access the same asset for any other type of open instance. On the other hand, when the “S” lock is used, read accesses of an asset can be obtained under the lock, and when the “S” lock is used another client computer can concurrently access the same asset but only for read accesses and metadata accesses.

[0028] As further shown in FIG. 2, the “W” lock can be used to obtain both read and write accesses of an asset, with any other concurrent access of the asset by another client computer being permissible. Moreover, the “U” lock can be used to obtain read and write accesses of an asset, and when the “U” lock is used another client computer concurrently can access the same asset but only for read and metadata accesses. On the other hand, when the “X” lock is used, read and write accesses of an asset can be obtained under the lock, and when the “X” lock is used another client computer can concurrently access the same asset but only for metadata accesses. The set of access privileges granted by a lock “L” can be designated “P_L”. In contrast, the set of sharing privileges restricted by a lock “L” can be designated “C_L”.

[0029] FIG. 3 illustrates a compatibility table 16, which shows which locks are compatible with which other locks. Check marks indicate compatibility. As intended by one preferred embodiment, two locks are compatible with each other if they mutually share the access modes that the other lock protects. Stated differently, in one presently preferred embodiment lock L_sis compatible with lock L_Tiff P_LsC_Ltand P_LtC_Ls.

[0030] Thus, for example, the “M” lock is compatible with all other locks that might happen to have been granted, the “R” lock is compatible with all other locks but the “X” lock, the “W” lock is compatible with the “M”, “R”, and “W” locks, the “S” lock is compatible with the “M”, “R”, and “S” locks, the “U” lock is compatible with the “M” and “U” locks, and the “X” lock is compatible only with other outstanding “X” locks.

[0031] As set forth further below, locks may require upgrading or downgrading. FIG. 4 shows the legal upgrades and downgrades between the MSRWUX locks. For example, as indicated by the arrows the “X” lock can be upgraded to any other lock, the “U” lock can be upgraded to any other lock but the “X” lock, the “W” and “S” locks can be upgraded to the “R” and “M” locks, and the “R” lock can be upgraded only to the “M” lock. In contrast, the “M” lock can be downgraded to any other lock, and the “R” lock can be downgraded to the “W”, “S”, and “U” locks.

[0032] FIG. 5 shows the server logic that is executed when a request for a semi-preemptible access lock L_Ris received by the server. Commencing at block 40, a request for an access lock is received. Moving to decision diamond 42, the server determines whether the requested lock is compatible with any other outstanding access lock. If it is determined at decision diamond 42 that the requested lock is compatible with all outstanding access locks, the process moves to block 44 to grant the requested lock.

[0033] In contrast, if the test at decision diamond 42 is negative, the logic moves to block 46 to demand all incompatible locks from the client computers that hold those locks. If any denials are received at decision diamond 48, the requested lock is denied at block 50; otherwise, the lock is granted at block 44.

[0034] FIG. 6 shows the logic executed by a client computer when a demand for a semipreemptible lock is received from the server. Commencing at block 70, the demand is received, and at decision diamond 72 it is determined whether any open instances exist that are protected by the demanded lock, i.e., whether any children nodes representing local locks exist under the root node representing the demanded lock in the client forest. If not, the lock is relinquished at block 74.

[0035] On the other hand, if open instances exist that are protected by the demanded semi-preemptible access lock, the logic flows to block 76 to determine the compatibility of each semi-preemptible access lock held by the client computer vis-a-vis the demanded lock. Proceeding to block 78, all locks that are incompatible with the demanded lock are added to an INCOMPATIBLE list, and then, at block 80, each lock in the INCOMPATIBLE list is attempted to be downgraded in accordance with the downgrades shown in FIG. 4, while still protecting any local instances, i.e., while still encapsulating any local file locks. If it is determined at decision diamond 82 that any downgrades failed, the requested lock is refused to be relinquished at block 84; otherwise, if all incompatible locks can be successfully downgraded as described further below, the client computer relinquishes the requested lock at block 86.

[0036] Should a client computer receive a request for a local open instance that requires a stronger access lock than the one held by the client computer, it invokes the logic above to request the required access lock. As recognized herein, the client never needs to upgrade from a held lock to a stronger incompatible lock, because that would mean the client is not using the full strength of its current access lock. Clients address this situation by downgrading their current access lock to an access lock that protects existing open instances, and then upgrading to the needed stronger lock.

[0037] While the particular SYSTEM FOR MANAGING ASSET ACCESS IN A DISTRIBUTED STORAGE SYSTEM as herein shown and described in detail is fully capable of attaining the above-described objects of the invention, it is to be understood that it is the presently preferred embodiment of the present invention and is thus representative of the subject matter which is broadly contemplated by the present invention, that the scope of the present invention fully encompasses other embodiments which may become obvious to those skilled in the art, and that the scope of the present invention is accordingly to be limited by nothing other than the appended claims, in which reference to an element in the singular means “at least one”. All structural and functional equivalents to the elements of the above-described preferred embodiment that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the present claims. Moreover, it is not necessary for a device or method to address each and every problem sought to be solved by the present invention, for it to be encompassed by the present claims. Furthermore, no element, component, or method step in the present disclosure is intended to be dedicated to the public regardless of whether the element, component, or method step is explicitly recited in the claims. No claim element herein is to be construed under the provisions of 35 U.S.C. §112, sixth paragraph, unless the element is expressly recited using the phrase “means for”.