US8990954B2 - Distributed lock manager for file system objects in a shared file system - Google Patents

Distributed lock manager for file system objects in a shared file system Download PDF

Info

Publication number
US8990954B2
US8990954B2 US11/765,912 US76591207A US8990954B2 US 8990954 B2 US8990954 B2 US 8990954B2 US 76591207 A US76591207 A US 76591207A US 8990954 B2 US8990954 B2 US 8990954B2
Authority
US
United States
Prior art keywords
token
file system
primary
shared
primary token
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related, expires
Application number
US11/765,912
Other versions
US20080319996A1 (en
Inventor
Steven D. Cook
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Priority to US11/765,912 priority Critical patent/US8990954B2/en
Assigned to INTERNATIONAL BUSINESS MACHINES CORPORATION reassignment INTERNATIONAL BUSINESS MACHINES CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: COOK, STEVEN D.
Priority to CNA2008101102172A priority patent/CN101329681A/en
Publication of US20080319996A1 publication Critical patent/US20080319996A1/en
Application granted granted Critical
Publication of US8990954B2 publication Critical patent/US8990954B2/en
Expired - Fee Related legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • G06F17/30171
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/17Details of further file system functions
    • G06F16/176Support for shared access to files; File sharing support
    • G06F16/1767Concurrency control, e.g. optimistic or pessimistic approaches
    • G06F16/1774Locking methods, e.g. locking methods for file systems allowing shared and concurrent access to files
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1415Saving, restoring, recovering or retrying at system level
    • G06F11/1435Saving, restoring, recovering or retrying at system level using file system or storage system metadata
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/18File system types
    • G06F16/1858Parallel file systems, i.e. file systems supporting multiple processors
    • G06F17/30224
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/604Tools and structures for managing or administering access control systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/465Distributed object oriented systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/52Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1095Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1097Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]

Definitions

  • This invention relates to a naive computer system created by layering a shared-nothing operating system with a shared file system. More specifically, the invention relates to mediating access to a shared object in the naive computer system.
  • a shared-nothing multi-processor is an environment where the processors are interconnected, but each processor has its own memory, cache, and disks. This type of multiprocessing environment is also referred to as a pure cluster.
  • Each processor in a shared-nothing environment is a complete stand-alone machine and runs a copy of an operating system. When such processors are connected by a local area network, the processors are loosely coupled. Similarly, when such processors are connected by a switch, the processors are tightly coupled. Communication between the processors in either of the above-described connections is done through a message passing protocol.
  • Each processor resource i.e.
  • a shared-nothing operating system in a shared-nothing operating system are not simultaneously accessed, used, or shared—only one processor at a time may own or use the resource.
  • the Microsoft Windows® operating system is an example of a shared-nothing operating system.
  • shared file systems which allow all interconnected processors and associated servers to share and use the same file system.
  • An example of a shared file systems includes a network file system in the form of a distributed file system that supports access to files and directories located on remote computers, and treats those files and directories as if they were local. More specifically, operating system commands can be used to create, remove, read, write, and set file attributes for remote files and directories.
  • a computer operating with a shared-nothing operating system does not typically function with a shared file system.
  • a shared-nothing environment may co-exist with a shared file system.
  • One example of co-existence of a shared-nothing protocol with a shared everything protocol is to install a high availability option with a shared-nothing protocol.
  • a high availability option is a system design protocol and implementation that ensures a certain absolute degree of operational continuity during a given measurement period.
  • This form of co-existence adds a shared-nothing functionality to a shared file system. More specifically, all processors in such a layered environment have access to the shared file system, but only one processor may own or use the file system at a time.
  • This invention comprises a method and system for arbitrating access to a shared object in a computing environment wherein a shared-nothing operating system is layered with a shared file system.
  • a method for managing a shared file system that co-exists with a server operating with a shared-nothing operating system.
  • a primary token is established in the computer system as a tool to control access to one or more shared objects in the file system.
  • the processor requests ownership of the primary token from a prior owner of the primary token, or if there is no current owner then the processor takes ownership of the primary token.
  • a secondary token is created. The secondary token is used to take ownership of the object in the file system protected by the primary token.
  • a computer system is provided with a shared file system, and a processor operating a shared-nothing operating system in communication with the shared file system.
  • a primary token is provided as an element to control access to a shared object in the file system.
  • a manager is provided to facilitate an ownership request of the primary token by the processor from a prior owner of the primary token.
  • a secondary token is issued. The secondary token is used to take ownership of the object in the file system protected by the primary token.
  • an article is provided with a tangible computer readable carrier including computer program instructions configured to manage a shared file system that co-exists with a shared-nothing operating system. Instructions are provided to establish a primary token in a computer system as an element to control access to an object in the file system as a shared resource. Instructions are provided to issue a request for ownership of the primary token from a requesting server to an owning server. In addition, instructions are provided to issue a secondary token in response to receipt of a silent, unexpected, or expected negative response from the prior owner of the primary token. The secondary token is used to take ownership of the object in the file system protected by the primary token.
  • a method for managing a shared file system that co-exists with a server operating with a shared-nothing operating system.
  • a primary token is established in the computer system as a tool to control access to one or more shared objects in the file system.
  • the processor requests ownership of the primary token from a prior owner of the primary token, or if there is no current owner then the processor takes ownership of the primary token. If a negative response is received from the prior owner of the primary token, a secondary token is created. The secondary token is used to take ownership of the object in the file system protected by the primary token.
  • FIG. 1 is a block diagram of a naive system with a locking mechanism.
  • FIG. 2 is a flow chart illustrating a method for mediating access to a shared object in a naive system.
  • FIGS. 3A and 3B are a flow chart illustrating a method for arbitrating token ownership according to the preferred embodiment of this invention, and is suggested for printing on the first page of the issued patent.
  • FIG. 4 is a flow chart illustrating a method for updating token ownership.
  • FIG. 5 is a block diagram of a file system locking tool embedded in a computer system.
  • naive systems that are unaware of shared file systems or data environments are considered naive.
  • Shared file system objects that are either unaware of or unable to handle and protect shared-nothing operating system requirements are also considered naive.
  • Such naive systems require tools to facilitate and manage reading from and writing to objects between a shared-nothing operating system and a shared file system to recognize, map, and coordinate the different layers of these naive systems.
  • FIG. 1 is a block diagram ( 100 ) illustrating one example of layering of computer systems to create a naive system. As shown, there are at least two operating systems, OS 1 ( 10 ) and OS 2 ( 20 ). Each of the operating systems OS 1 ( 10 ) and OS 2 ( 20 ) are shared-nothing operating systems. OS 1 ( 10 ) is shown with two applications ( 12 ) and ( 14 ) operating within the system, and OS 2 ( 20 ) is shown with two applications ( 22 ) and ( 24 ) operating within the system. In one embodiment, there may be fewer applications operating within the file system or more applications operating within the file system. The invention should not be limited to the quantity of operating systems or applications shown herein.
  • Each of the operating systems, OS 1 ( 10 ) and OS 2 ( 20 ), are in communication with a shared access file system ( 30 ) layers on a shared data hardware environment ( 40 ).
  • a file system locking mechanism ( 50 a ), ( 50 b ) is provided for each operating system, OS 1 ( 10 ) and OS 2 ( 20 ), respectively, to facilitate and mediate sharing of objects between the shared file system ( 30 ) and the shared-nothing operating systems OS 1 ( 10 ) and OS 2 ( 20 ).
  • the file system locking mechanisms ( 50 a ) and ( 50 b ) are filters.
  • the mechanism ( 50 a ), ( 50 b ) should not be limited to use of a filter and may be any mechanism that is capable of providing the necessary functions.
  • the file system locking mechanism ( 50 a ), ( 50 b ) may be in the form of a driver or a SCSI protocol.
  • the locking mechanism coordinates different locking layers of the operating systems, the file systems, and the data environment.
  • FIGS. 2-4 below describe in detail the functionality of the file system locking mechanism.
  • the file system locking mechanism functions as a manager to facilitate negotiation of temporary ownership of an object in the file system to an application requesting ownership of the object. Accordingly, a tool is provided to facilitate access to objects in the shared file system to support layering in a naive system.
  • FIG. 2 is a flow chart ( 200 ) demonstrating a method for a server operating a shared-nothing operating system to temporarily access an object in a shared file system environment in communication with the server, while satisfying the shared-nothing expectation of a shared-nothing operating system.
  • the server operating the shared-nothing operating system finds the shared file system ( 202 ).
  • the process of finding the shared file system may occur at time of boot of the server, during loading of a driver, file, etc., or at any time that the server finds the shared file system.
  • the server is in communication with the shared file system and may access objects in the file system.
  • the file system locking mechanism searches for an ownership token in the file system for the requested object ( 204 ).
  • An ownership token is a management apparatus in the file system that allows multiple servers and operating systems to have access to the same storage media or file system while providing temporary ownership of one or more objects in that file system to a server in communication with the file system.
  • the ownership token may be a file, a directory, metadata, etc.
  • token ownership is embedded in the token.
  • token ownership may be in the form of a server identifier that is embedded in the token. This enables the file system locking mechanism to determine server ownership through the token itself. If the response to the determination at step ( 206 ) is positive, the requesting server temporarily owns the requested object identified by the token. The requesting server in possession of the token may access the requested object, e.g. read and/or write to the object, associated with the token ( 208 ). In one embodiment, the requested object may include directory contents for a requested file.
  • the file system locking mechanism may attempt to take ownership of the requested object of the associated token on behalf of the requesting server ( 210 ).
  • a determination is conducted by the file system locking mechanism as to whether the file system locking mechanism successfully took possession of the ownership token for the requesting server ( 212 ). If the response to the determination at step ( 212 ) is positive, the file system locking mechanism transfers the token to the requesting server and the requesting server in possession of the token may access the requested object identified by the token ( 208 ). Conversely, if the response to the determination at step ( 212 ) is negative, this is an indication that the token associated with the requested object is not available.
  • An arbitration error is returned to the server by the file system locking mechanism ( 214 ).
  • the file system locking mechanism may request the token at a later time depending upon the access needs of the server. Possession of the token in a na ⁇ ve file system provides the server in possession of the token with temporary ownership or one or more shared objects in the shared file system. Accordingly, the server operating with a shared-nothing operating system and in communication with a shared file system may access and temporarily own one or more shared objects in the shared file system through the file system locking mechanism.
  • a token is utilized to grant temporary access of an object to a server operating a naive operating system in communication with a shared file system.
  • the grant of the token is for temporary ownership, and when the server has completed the task, e.g. read and/or write, associated with the requested object, the token must be surrendered to the next requesting server.
  • the existing owner of the token can release the token when finished using the resource.
  • 3A and 3B are a flow chart ( 300 ) demonstrating a process for arbitrating token ownership and access to a shared object when there is a miscommunication among the servers in communication with the shared file system.
  • a server Server 1
  • the server assumes that the requested object is not a shared object.
  • a file system locking mechanism in communication with the server, Server 1 , requests the ownership token in the form of a primary token to transfer to the requesting server in order for the requesting server to obtain temporary ownership of one or more objects in the file system ( 302 ).
  • the file system locking mechanism searches for the primary token in the file system for the requested object ( 304 ).
  • a primary token is a management apparatus in the file system that allows multiple servers and operating systems to have access to the same storage media or file system while providing temporary ownership of one or more objects in that file system to a server in communication with the file system.
  • the primary token may be a file, a directory, metadata, etc.
  • the server Since the server is part of naive file system it does not have knowledge of the token. If the response to the determination at step ( 306 ) is positive, the requesting server, Server 1 , temporarily owns the requested object identified by the primary token. The requesting server, Server 1 , in possession of the primary token may access the requested object associated with the primary token ( 308 ). In one embodiment, the requested object may include directory contents for a requested file. Conversely, if the response to the determination at step ( 306 ) is negative, the file system locking mechanism may attempt to take ownership of associated primary token on behalf of the requesting server ( 310 ).
  • step ( 310 ) a determination is conducted as to whether the file system locking mechanism successfully took ownership of the primary token for the requesting server, Server 1 , ( 312 ). If the response to the determination at step ( 312 ) is positive, file system locking mechanism transfers the token to the requesting server, Server 1 and the requesting server, Server 1 , in possession of the primary token may access the requested object identified by the primary token ( 308 ). Conversely, if the response to the determination at step ( 312 ) is negative, this is an indication that the primary token associated with the requested object is not available. Thereafter, a determination is conducted as to whether the requested primary token was recently updated ( 314 ). FIG. 4 below demonstrates one embodiment of how a token is updated.
  • a positive response to the determination at step ( 314 ) is an indication that the prior owner of the primary token is continuing to access the shared object and has asserted its right to the access by continuing to utilize the primary token.
  • the requesting server, Server 1 is informed by the file system locking mechanism of the continued use of the primary token by another server through an arbitration error message ( 316 ). Accordingly, a primary token that is actively being used by another server may continue to be actively owned by that server.
  • the response to the determination at step ( 314 ) is negative, this is an indication that the prior owner of the primary token may be continuing to retain possession of the primary token but not using the primary token.
  • it To determine the status of the primary token and the owner, it must be determined if the owning server is in communication with the file system and/or other servers in the network ( 318 ). In one embodiment, such a determination is conducted with the use of a heartbeat message protocol. In a cluster environment, heartbeat messages are periodically communicated among the members of the cluster, and the file system locking mechanism may monitor the periodic heartbeat to determine if the owning server is in communication with the file system.
  • the file system locking mechanism may issue a heartbeat message or similar communication protocol to the owning server, wherein the message or communication protocol includes a request for a return reply from the recipient. Regardless of the communication protocol employed, the file system locking mechanism initiates the communication protocol because the file system locking mechanism determines whether or not it takes ownership of the token. If the response to the determination at step ( 318 ) is positive, this is an indication that the server in possession of the primary token is in communication with the file system and retains possession of the primary token ( 320 ). However, if the response to the determination at step ( 318 ) is negative, this is an indication that the server in possession of the primary token has temporarily or permanently ceased communication with other servers in the network ( 322 ).
  • the file system locking mechanism requesting the primary token on behalf of a requesting server may receive a response that is an unexpected response and does not address whether or not the owning server is in communication with the file system and/or other servers in the network.
  • a response is considered inappropriate, e.g. unexpected, in that it does not address the availability of the primary token.
  • Examples of an inappropriate response may include a response that is neither a grant of the token nor a denial of the request for the token.
  • the server in possession of the primary token may not be using the primary token but at the same time may be unable to return the primary token to the file system since there is a temporary or permanent cessation of communication.
  • the file system locking mechanism may proceed to acquire a token for the requested object on behalf of the requesting server, Server 1 .
  • the first step is to assume that the server in possession of the primary token is somehow detached from the file system ( 322 ).
  • the file system lock mechanism broadcasts a message to all servers in communication with the file system on behalf of requesting server, Server 1 , that the server in possession of the token is unavailable and that the primary token held by that server is being invalidated ( 324 ). Thereafter, the file system locking mechanism takes ownership of a new token on behalf of the requesting server, Server 1 ( 326 ).
  • the new token is hereinafter referred to as a secondary token.
  • the type of the secondary token and its location may be predetermined and stored in a static location in the file system, such as the Windows Registry or the Unix config files, or it may be newly created as needed and then the token information can be broadcast to all file system locking mechanisms from the creating server.
  • a determination is conducted as to whether the acquisition by the file system locking mechanism on behalf of at step ( 326 ) was successful ( 328 ). If the response to the determination at step ( 328 ) is positive, the requesting server in possession of the secondary token may access the requested object identified by the token ( 330 ). Conversely, if the response to the determination at step ( 328 ) is negative, this is an indication that the secondary token associated with the requested object is not available.
  • An arbitration error is returned to the file system locking mechanism associated with the requesting server, and the file system locking mechanism communicates an access denial of the token to the requesting server ( 332 ).
  • the server may request access to the file system object at a later time at which time the file system locking mechanism would again arbitrate handling of the associated token depending upon the access needs of the server.
  • the secondary token may be used until such time as the original token again becomes available to the file system, and at such time, the secondary token may be released and invalidated to prevent a conflict between two active tokens for a specified object. Accordingly, the server operating with a shared-nothing operating system and in communication with a shared file system may access a secondary token under limited circumstances in order to access and temporarily own a shared object in the shared file system.
  • FIG. 4 is a flow chart ( 400 ) illustrating a process for periodically updating token ownership in the file system.
  • the token update process is initiated by the server in possession of the primary token ( 402 ).
  • the server(s) request access to an object in the file system, and the file system locking mechanism translates the access request to a request for token ownership.
  • the file system may have more than one primary token available with each of the primary tokens specified for different objects in the file system.
  • the total number of owned tokens in the file system is assigned to the variable N total ( 404 ), and the variable N is assigned to the integer one ( 406 ).
  • the variable N is a counting variable to count the number of owned tokens in the file system.
  • the owned token, Token N is specified ( 408 ), and a determination is conducted as to whether Token N is a secondary token created in response to possession of a primary token by a non-responsive server ( 410 ). If it is determined that Token N is a primary token, the file system locking mechanism in communication with the server in possession of Token N may update Token N to the file system ( 412 ).
  • a token update may be in the form of a message communicated to the file system locking mechanism on each of the servers which are servers in communication with the file system of the continued use of Token N by the owning server. However, if it is determined that Token N is not a primary token; a subsequent determination is conducted as to whether the primary token is available ( 414 ). A negative response to the determination at step ( 414 ) will result in the file system locking mechanism in communication with the server in possession of Token N to update Token N to the file system ( 412 ).
  • step ( 414 ) if it is determined at step ( 414 ) that the primary token is available, then the file system lock mechanism in communication with the server in possession of the secondary replacement token arbitrates the primary token to re-acquire ownership of the primary token on behalf of the associated server ( 416 ).
  • step ( 416 ) a determination is conducted as to whether the file system locking mechanism for the server in possession of the replacement secondary token successfully arbitrated the primary token ( 418 ). If it is determined that the file system locking mechanism associated with the requesting server was not successful in arbitrating the primary token, then the requesting server may update Token N to the file system ( 412 ).
  • the file system lock mechanism broadcasts the primary token and invalidates the secondary replacement token on behalf of the requesting server ( 420 ).
  • the variable N is incremented ( 422 ) to proceed to evaluating the next token in the file system.
  • a determination is conducted as to whether there are any more tokens subject to evaluation ( 424 ). In one embodiment, the determination at step ( 424 ) may be a comparison of the incremented counter to the variable N total .
  • step ( 424 ) If it is determined at step ( 424 ) that there is at least one more token to be evaluated, the process returns to step ( 408 ). Conversely, if it is determined at step ( 424 ) that all of the tokens have been evaluated, the process is completed. In one embodiment, completion of the token update process may include waiting a preset time interval prior to re-starting the token update process ( 426 ). Accordingly, the process outlined herein releases and invalidates replacement secondary tokens at such time as a primary token again becomes available.
  • the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.
  • the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system.
  • a computer-usable or computer readable medium can be any apparatus that can contain, or store the program for use by or in connection with the instruction execution system, apparatus, or device.
  • FIG. 5 is a block diagram ( 500 ) illustrating placement of the file system locking tool in a computer system.
  • the illustration shows a server ( 502 ) with a processor ( 504 ), memory ( 506 ) in communication with a shared file system ( 520 ) and shared storage media ( 525 ).
  • the server ( 502 ) may operate one or more applications ( 514 ) and ( 516 ) in a shared-nothing operating system ( 508 ).
  • a file system locking tool in the form of a manager ( 540 ) is shown residing in memory ( 506 ) of the server ( 502 ).
  • the manager ( 540 ) also known as the file system locking mechanism, mediates and facilitates locking of shared objects to support co-existence of the shared-nothing operating system and the shared file system, as described in detail in FIGS. 2-4 above.
  • the manager ( 540 ) may utilize instructions in a computer readable medium to mediate reading and writing of shared objects between the shared-nothing operating system and the shared file system.
  • the manager ( 540 ) utilizes a token (not shown) as a tool to facilitate the mediation.
  • the token may be in the form of a file, a directory, meta data, an attribute of the file system, and an object in the file system.
  • the manager ( 540 ) may reside as a hardware tool external to memory ( 506 ), or it may be implemented as a combination of hardware and software. Accordingly, the manager ( 540 ) may be implemented as a software tool or a hardware tool to facilitate mediation of a shared object between a shared-nothing operating system layered with a shared file system.
  • Embodiments within the scope of the present invention also include articles of manufacture comprising program storage means having encoded therein program code.
  • program storage means can be any available media which can be accessed by a general purpose or special purpose computer.
  • program storage means can include RAM, ROM, EEPROM, CD-ROM, or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired program code means and which can be accessed by a general purpose or special purpose computer. Combinations of the above should also be included in the scope of the program storage means.
  • the medium can be an electronic, magnetic, optical, or semiconductor system (or apparatus or device).
  • Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, random access memory (RAM), read-only memory (ROM), a rigid magnetic disk, and an optical disk.
  • Current examples of optical disks include compact disk B read only (CD-ROM), compact disk B read/write (CD-R/W) and DVD.
  • a data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus.
  • the memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.
  • I/O devices can be coupled to the system either directly or through intervening I/O controllers.
  • Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks.
  • the software implementation can take the form of a computer program product accessible from a computer-useable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system.
  • Layering of a shared-nothing operating system with a shared file system produces an environment that includes the benefits of both systems.
  • the file system locking mechanism is a management tool utilized to leverage, mediate, and/or facilitate read and write of shared objects present in the combined environment to support the mediation at the file system level.
  • the servers operating in a naive environment request access to one or more shared objects and a file system locking mechanism associated with the server translates that to a request for ownership token.
  • both a primary token and a secondary token are utilized in limited circumstances to provide access to a shared object in a naive environment.
  • the secondary token may be in the same form as the primary token, or in a different form.
  • the primary token is a file
  • the secondary token may also be a file, an attribute of the file system, etc.
  • the primary token is a directory
  • the secondary token may also be a directory, a file, an attribute of the file system, etc.

Abstract

A method and apparatus are provided for mediating access to a shared object in a naive computer system having a shared-nothing operating system layered on a shared file system. At least one primary token is utilized as a tool to mediate ownership of one or more shared objects in the naive system. A secondary token is created and utilized to mediate ownership of one or more shared objects. The secondary token created and utilized in limited circumstances, such as when the owner of the primary token ceases communicating with one or more requesters of the primary token.

Description

BACKGROUND OF THE INVENTION
1. Technical Field
This invention relates to a naive computer system created by layering a shared-nothing operating system with a shared file system. More specifically, the invention relates to mediating access to a shared object in the naive computer system.
2. Description of the Prior Art
A shared-nothing multi-processor is an environment where the processors are interconnected, but each processor has its own memory, cache, and disks. This type of multiprocessing environment is also referred to as a pure cluster. Each processor in a shared-nothing environment is a complete stand-alone machine and runs a copy of an operating system. When such processors are connected by a local area network, the processors are loosely coupled. Similarly, when such processors are connected by a switch, the processors are tightly coupled. Communication between the processors in either of the above-described connections is done through a message passing protocol. Each processor resource, i.e. memory, storage, file systems, IP addresses, etc., in a shared-nothing operating system are not simultaneously accessed, used, or shared—only one processor at a time may own or use the resource. The Microsoft Windows® operating system is an example of a shared-nothing operating system.
In contrast to the shared-nothing multi-processor environment, there are shared file systems which allow all interconnected processors and associated servers to share and use the same file system. This includes servers with different operating systems. An example of a shared file systems includes a network file system in the form of a distributed file system that supports access to files and directories located on remote computers, and treats those files and directories as if they were local. More specifically, operating system commands can be used to create, remove, read, write, and set file attributes for remote files and directories.
It is known in the art that a computer operating with a shared-nothing operating system does not typically function with a shared file system. However, a shared-nothing environment may co-exist with a shared file system. One example of co-existence of a shared-nothing protocol with a shared everything protocol is to install a high availability option with a shared-nothing protocol. A high availability option is a system design protocol and implementation that ensures a certain absolute degree of operational continuity during a given measurement period. This form of co-existence adds a shared-nothing functionality to a shared file system. More specifically, all processors in such a layered environment have access to the shared file system, but only one processor may own or use the file system at a time. This reflects the shared-nothing operating system ignorance of the shared data environment. Accordingly, there is a need to enhance access to and sharing of objects in the shared file system in a co-existence environment, such as a tool to support multiple servers in the layered environment owning and using the shared file system.
SUMMARY OF THE INVENTION
This invention comprises a method and system for arbitrating access to a shared object in a computing environment wherein a shared-nothing operating system is layered with a shared file system.
In one aspect of the invention, a method is provided for managing a shared file system that co-exists with a server operating with a shared-nothing operating system. A primary token is established in the computer system as a tool to control access to one or more shared objects in the file system. The processor requests ownership of the primary token from a prior owner of the primary token, or if there is no current owner then the processor takes ownership of the primary token. In response to receipt of a silent, unexpected, or expected negative response from the prior owner of the primary token, a secondary token is created. The secondary token is used to take ownership of the object in the file system protected by the primary token.
In another aspect of the invention, a computer system is provided with a shared file system, and a processor operating a shared-nothing operating system in communication with the shared file system. A primary token is provided as an element to control access to a shared object in the file system. In addition, a manager is provided to facilitate an ownership request of the primary token by the processor from a prior owner of the primary token. Upon receipt of a silent, unexpected, or expected negative response by the manager from the prior owner of the primary token, a secondary token is issued. The secondary token is used to take ownership of the object in the file system protected by the primary token.
In yet another aspect of the invention, an article is provided with a tangible computer readable carrier including computer program instructions configured to manage a shared file system that co-exists with a shared-nothing operating system. Instructions are provided to establish a primary token in a computer system as an element to control access to an object in the file system as a shared resource. Instructions are provided to issue a request for ownership of the primary token from a requesting server to an owning server. In addition, instructions are provided to issue a secondary token in response to receipt of a silent, unexpected, or expected negative response from the prior owner of the primary token. The secondary token is used to take ownership of the object in the file system protected by the primary token.
In an even further aspect of the invention, a method is provided for managing a shared file system that co-exists with a server operating with a shared-nothing operating system. A primary token is established in the computer system as a tool to control access to one or more shared objects in the file system. The processor requests ownership of the primary token from a prior owner of the primary token, or if there is no current owner then the processor takes ownership of the primary token. If a negative response is received from the prior owner of the primary token, a secondary token is created. The secondary token is used to take ownership of the object in the file system protected by the primary token.
Other features and advantages of this invention will become apparent from the following detailed description of the presently preferred embodiment of the invention, taken in conjunction with the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram of a naive system with a locking mechanism.
FIG. 2 is a flow chart illustrating a method for mediating access to a shared object in a naive system.
FIGS. 3A and 3B are a flow chart illustrating a method for arbitrating token ownership according to the preferred embodiment of this invention, and is suggested for printing on the first page of the issued patent.
FIG. 4 is a flow chart illustrating a method for updating token ownership.
FIG. 5 is a block diagram of a file system locking tool embedded in a computer system.
DESCRIPTION OF THE PREFERRED EMBODIMENT Overview
Operating systems that are unaware of shared file systems or data environments are considered naive. Shared file system objects that are either unaware of or unable to handle and protect shared-nothing operating system requirements are also considered naive. Such naive systems require tools to facilitate and manage reading from and writing to objects between a shared-nothing operating system and a shared file system to recognize, map, and coordinate the different layers of these naive systems.
Technical Details
FIG. 1 is a block diagram (100) illustrating one example of layering of computer systems to create a naive system. As shown, there are at least two operating systems, OS1 (10) and OS2 (20). Each of the operating systems OS1 (10) and OS2 (20) are shared-nothing operating systems. OS1 (10) is shown with two applications (12) and (14) operating within the system, and OS2 (20) is shown with two applications (22) and (24) operating within the system. In one embodiment, there may be fewer applications operating within the file system or more applications operating within the file system. The invention should not be limited to the quantity of operating systems or applications shown herein. Each of the operating systems, OS1 (10) and OS2 (20), are in communication with a shared access file system (30) layers on a shared data hardware environment (40). A file system locking mechanism (50 a), (50 b) is provided for each operating system, OS1 (10) and OS2 (20), respectively, to facilitate and mediate sharing of objects between the shared file system (30) and the shared-nothing operating systems OS1 (10) and OS2 (20). As shown herein, the file system locking mechanisms (50 a) and (50 b) are filters. However, the mechanism (50 a), (50 b) should not be limited to use of a filter and may be any mechanism that is capable of providing the necessary functions. In one embodiment, the file system locking mechanism (50 a), (50 b) may be in the form of a driver or a SCSI protocol. The locking mechanism coordinates different locking layers of the operating systems, the file systems, and the data environment. FIGS. 2-4 below describe in detail the functionality of the file system locking mechanism. In one embodiment, the file system locking mechanism functions as a manager to facilitate negotiation of temporary ownership of an object in the file system to an application requesting ownership of the object. Accordingly, a tool is provided to facilitate access to objects in the shared file system to support layering in a naive system.
FIG. 2 is a flow chart (200) demonstrating a method for a server operating a shared-nothing operating system to temporarily access an object in a shared file system environment in communication with the server, while satisfying the shared-nothing expectation of a shared-nothing operating system. Initially, the server operating the shared-nothing operating system finds the shared file system (202). In one embodiment, the process of finding the shared file system may occur at time of boot of the server, during loading of a driver, file, etc., or at any time that the server finds the shared file system. Following step (202), the server is in communication with the shared file system and may access objects in the file system. At such time as the server requests access to an object in the file system, the file system locking mechanism searches for an ownership token in the file system for the requested object (204). An ownership token is a management apparatus in the file system that allows multiple servers and operating systems to have access to the same storage media or file system while providing temporary ownership of one or more objects in that file system to a server in communication with the file system. In one embodiment, the ownership token may be a file, a directory, metadata, etc. When the file system locking mechanism has completed its search, a determination is conducted by the file system locking mechanism as to whether the requesting server is in possession of the ownership token (206). The server may be returning from a crash or other form of shut-down. Since the server is part of naive file system it does not have knowledge of the token. In one embodiment, token ownership is embedded in the token. For example, token ownership may be in the form of a server identifier that is embedded in the token. This enables the file system locking mechanism to determine server ownership through the token itself. If the response to the determination at step (206) is positive, the requesting server temporarily owns the requested object identified by the token. The requesting server in possession of the token may access the requested object, e.g. read and/or write to the object, associated with the token (208). In one embodiment, the requested object may include directory contents for a requested file. Conversely, if the response to the determination at step (206) is negative, the file system locking mechanism may attempt to take ownership of the requested object of the associated token on behalf of the requesting server (210). Following step (210), a determination is conducted by the file system locking mechanism as to whether the file system locking mechanism successfully took possession of the ownership token for the requesting server (212). If the response to the determination at step (212) is positive, the file system locking mechanism transfers the token to the requesting server and the requesting server in possession of the token may access the requested object identified by the token (208). Conversely, if the response to the determination at step (212) is negative, this is an indication that the token associated with the requested object is not available. An arbitration error is returned to the server by the file system locking mechanism (214). The file system locking mechanism may request the token at a later time depending upon the access needs of the server. Possession of the token in a naïve file system provides the server in possession of the token with temporary ownership or one or more shared objects in the shared file system. Accordingly, the server operating with a shared-nothing operating system and in communication with a shared file system may access and temporarily own one or more shared objects in the shared file system through the file system locking mechanism.
As described above, a token is utilized to grant temporary access of an object to a server operating a naive operating system in communication with a shared file system. The grant of the token is for temporary ownership, and when the server has completed the task, e.g. read and/or write, associated with the requested object, the token must be surrendered to the next requesting server. In the event that there is no server requesting the token, the existing owner of the token can release the token when finished using the resource. However, in some circumstances with multiple servers in communication with the shared file system, it is possible that a prior owner of the token may cease communicating with the next requesting server and therefore may not be able to transfer ownership of the token. FIGS. 3A and 3B are a flow chart (300) demonstrating a process for arbitrating token ownership and access to a shared object when there is a miscommunication among the servers in communication with the shared file system. Initially, a server, Server1, requests access to a file system object. However, since the server is part of a naive computer system, the server assumes that the requested object is not a shared object. A file system locking mechanism in communication with the server, Server1, requests the ownership token in the form of a primary token to transfer to the requesting server in order for the requesting server to obtain temporary ownership of one or more objects in the file system (302). Following the server request at (302), the file system locking mechanism searches for the primary token in the file system for the requested object (304). A primary token is a management apparatus in the file system that allows multiple servers and operating systems to have access to the same storage media or file system while providing temporary ownership of one or more objects in that file system to a server in communication with the file system. In one embodiment, the primary token may be a file, a directory, metadata, etc. When the file system locking mechanism has completed its search, a determination is conducted by the file system locking mechanism as to whether the requesting server, Server1, is in possession of the requested primary token (306). The server may be returning from a crash or other form of shut-down. Since the server is part of naive file system it does not have knowledge of the token. If the response to the determination at step (306) is positive, the requesting server, Server1, temporarily owns the requested object identified by the primary token. The requesting server, Server1, in possession of the primary token may access the requested object associated with the primary token (308). In one embodiment, the requested object may include directory contents for a requested file. Conversely, if the response to the determination at step (306) is negative, the file system locking mechanism may attempt to take ownership of associated primary token on behalf of the requesting server (310). Following step (310), a determination is conducted as to whether the file system locking mechanism successfully took ownership of the primary token for the requesting server, Server1, (312). If the response to the determination at step (312) is positive, file system locking mechanism transfers the token to the requesting server, Server1 and the requesting server, Server1, in possession of the primary token may access the requested object identified by the primary token (308). Conversely, if the response to the determination at step (312) is negative, this is an indication that the primary token associated with the requested object is not available. Thereafter, a determination is conducted as to whether the requested primary token was recently updated (314). FIG. 4 below demonstrates one embodiment of how a token is updated. A positive response to the determination at step (314) is an indication that the prior owner of the primary token is continuing to access the shared object and has asserted its right to the access by continuing to utilize the primary token. In one embodiment, the requesting server, Server1, is informed by the file system locking mechanism of the continued use of the primary token by another server through an arbitration error message (316). Accordingly, a primary token that is actively being used by another server may continue to be actively owned by that server.
However, if the response to the determination at step (314) is negative, this is an indication that the prior owner of the primary token may be continuing to retain possession of the primary token but not using the primary token. To determine the status of the primary token and the owner, it must be determined if the owning server is in communication with the file system and/or other servers in the network (318). In one embodiment, such a determination is conducted with the use of a heartbeat message protocol. In a cluster environment, heartbeat messages are periodically communicated among the members of the cluster, and the file system locking mechanism may monitor the periodic heartbeat to determine if the owning server is in communication with the file system. Similarly, in one embodiment, the file system locking mechanism may issue a heartbeat message or similar communication protocol to the owning server, wherein the message or communication protocol includes a request for a return reply from the recipient. Regardless of the communication protocol employed, the file system locking mechanism initiates the communication protocol because the file system locking mechanism determines whether or not it takes ownership of the token. If the response to the determination at step (318) is positive, this is an indication that the server in possession of the primary token is in communication with the file system and retains possession of the primary token (320). However, if the response to the determination at step (318) is negative, this is an indication that the server in possession of the primary token has temporarily or permanently ceased communication with other servers in the network (322). In one embodiment, the file system locking mechanism requesting the primary token on behalf of a requesting server may receive a response that is an unexpected response and does not address whether or not the owning server is in communication with the file system and/or other servers in the network. Such a response is considered inappropriate, e.g. unexpected, in that it does not address the availability of the primary token. Examples of an inappropriate response may include a response that is neither a grant of the token nor a denial of the request for the token. In another example, the server in possession of the primary token may not be using the primary token but at the same time may be unable to return the primary token to the file system since there is a temporary or permanent cessation of communication.
The file system locking mechanism may proceed to acquire a token for the requested object on behalf of the requesting server, Server1. The first step is to assume that the server in possession of the primary token is somehow detached from the file system (322). The file system lock mechanism broadcasts a message to all servers in communication with the file system on behalf of requesting server, Server1, that the server in possession of the token is unavailable and that the primary token held by that server is being invalidated (324). Thereafter, the file system locking mechanism takes ownership of a new token on behalf of the requesting server, Server1 (326). The new token is hereinafter referred to as a secondary token. The type of the secondary token and its location may be predetermined and stored in a static location in the file system, such as the Windows Registry or the Unix config files, or it may be newly created as needed and then the token information can be broadcast to all file system locking mechanisms from the creating server. Following the ownership of the secondary token, a determination is conducted as to whether the acquisition by the file system locking mechanism on behalf of at step (326) was successful (328). If the response to the determination at step (328) is positive, the requesting server in possession of the secondary token may access the requested object identified by the token (330). Conversely, if the response to the determination at step (328) is negative, this is an indication that the secondary token associated with the requested object is not available. An arbitration error is returned to the file system locking mechanism associated with the requesting server, and the file system locking mechanism communicates an access denial of the token to the requesting server (332). The server may request access to the file system object at a later time at which time the file system locking mechanism would again arbitrate handling of the associated token depending upon the access needs of the server. In one embodiment, the secondary token may be used until such time as the original token again becomes available to the file system, and at such time, the secondary token may be released and invalidated to prevent a conflict between two active tokens for a specified object. Accordingly, the server operating with a shared-nothing operating system and in communication with a shared file system may access a secondary token under limited circumstances in order to access and temporarily own a shared object in the shared file system.
As illustrated above, in limited circumstances, the server in possession of the primary token may cease communicating with the file system and the primary token owned by the server may be invalidated by another requesting server. In one embodiment, token ownership is periodically updated in the file system to prevent invalidation attempts of an owned and active primary token. FIG. 4 is a flow chart (400) illustrating a process for periodically updating token ownership in the file system. The token update process is initiated by the server in possession of the primary token (402). The server(s) request access to an object in the file system, and the file system locking mechanism translates the access request to a request for token ownership. In one embodiment, the file system may have more than one primary token available with each of the primary tokens specified for different objects in the file system. The total number of owned tokens in the file system is assigned to the variable Ntotal (404), and the variable N is assigned to the integer one (406). The variable N is a counting variable to count the number of owned tokens in the file system. The owned token, TokenN is specified (408), and a determination is conducted as to whether TokenN is a secondary token created in response to possession of a primary token by a non-responsive server (410). If it is determined that TokenN is a primary token, the file system locking mechanism in communication with the server in possession of TokenN may update TokenN to the file system (412). In one embodiment, a token update may be in the form of a message communicated to the file system locking mechanism on each of the servers which are servers in communication with the file system of the continued use of TokenN by the owning server. However, if it is determined that TokenN is not a primary token; a subsequent determination is conducted as to whether the primary token is available (414). A negative response to the determination at step (414) will result in the file system locking mechanism in communication with the server in possession of TokenN to update TokenN to the file system (412). However, if it is determined at step (414) that the primary token is available, then the file system lock mechanism in communication with the server in possession of the secondary replacement token arbitrates the primary token to re-acquire ownership of the primary token on behalf of the associated server (416). Following step (416), a determination is conducted as to whether the file system locking mechanism for the server in possession of the replacement secondary token successfully arbitrated the primary token (418). If it is determined that the file system locking mechanism associated with the requesting server was not successful in arbitrating the primary token, then the requesting server may update TokenN to the file system (412). However, if it is determined that the file system lock mechanism was successful in arbitrating the primary token on behalf of the requesting server, then the file system lock mechanism broadcasts the primary token and invalidates the secondary replacement token on behalf of the requesting server (420). Following steps (412) and (420), the variable N is incremented (422) to proceed to evaluating the next token in the file system. However, prior to evaluating the next token, a determination is conducted as to whether there are any more tokens subject to evaluation (424). In one embodiment, the determination at step (424) may be a comparison of the incremented counter to the variable Ntotal. If it is determined at step (424) that there is at least one more token to be evaluated, the process returns to step (408). Conversely, if it is determined at step (424) that all of the tokens have been evaluated, the process is completed. In one embodiment, completion of the token update process may include waiting a preset time interval prior to re-starting the token update process (426). Accordingly, the process outlined herein releases and invalidates replacement secondary tokens at such time as a primary token again becomes available.
In one embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc. The invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, or store the program for use by or in connection with the instruction execution system, apparatus, or device.
FIG. 5 is a block diagram (500) illustrating placement of the file system locking tool in a computer system. The illustration shows a server (502) with a processor (504), memory (506) in communication with a shared file system (520) and shared storage media (525). As shown in FIG. 1, the server (502) may operate one or more applications (514) and (516) in a shared-nothing operating system (508). A file system locking tool in the form of a manager (540) is shown residing in memory (506) of the server (502). The manager (540), also known as the file system locking mechanism, mediates and facilitates locking of shared objects to support co-existence of the shared-nothing operating system and the shared file system, as described in detail in FIGS. 2-4 above. The manager (540) may utilize instructions in a computer readable medium to mediate reading and writing of shared objects between the shared-nothing operating system and the shared file system. In one embodiment, the manager (540) utilizes a token (not shown) as a tool to facilitate the mediation. The token may be in the form of a file, a directory, meta data, an attribute of the file system, and an object in the file system. Similarly, in one embodiment, the manager (540) may reside as a hardware tool external to memory (506), or it may be implemented as a combination of hardware and software. Accordingly, the manager (540) may be implemented as a software tool or a hardware tool to facilitate mediation of a shared object between a shared-nothing operating system layered with a shared file system.
Embodiments within the scope of the present invention also include articles of manufacture comprising program storage means having encoded therein program code. Such program storage means can be any available media which can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such program storage means can include RAM, ROM, EEPROM, CD-ROM, or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired program code means and which can be accessed by a general purpose or special purpose computer. Combinations of the above should also be included in the scope of the program storage means.
The medium can be an electronic, magnetic, optical, or semiconductor system (or apparatus or device). Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, random access memory (RAM), read-only memory (ROM), a rigid magnetic disk, and an optical disk. Current examples of optical disks include compact disk B read only (CD-ROM), compact disk B read/write (CD-R/W) and DVD.
A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.
Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers. Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks.
The software implementation can take the form of a computer program product accessible from a computer-useable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system.
Advantages Over the Prior Art
Layering of a shared-nothing operating system with a shared file system produces an environment that includes the benefits of both systems. The file system locking mechanism is a management tool utilized to leverage, mediate, and/or facilitate read and write of shared objects present in the combined environment to support the mediation at the file system level. The servers operating in a naive environment request access to one or more shared objects and a file system locking mechanism associated with the server translates that to a request for ownership token. There may be a primary token and/or a secondary token in the file system. Both the primary and secondary tokens are utilized in a manner to support access to one or more shared objects without violating the protocols of either the shared-nothing operating system or the shared file system.
Alternative Embodiments
It will be appreciated that, although specific embodiments of the invention have been described herein for purposes of illustration, various modifications may be made without departing from the spirit and scope of the invention. In particular, both a primary token and a secondary token are utilized in limited circumstances to provide access to a shared object in a naive environment. The secondary token may be in the same form as the primary token, or in a different form. For example, if the primary token is a file, then the secondary token may also be a file, an attribute of the file system, etc. Similarly, if the primary token is a directory, then the secondary token may also be a directory, a file, an attribute of the file system, etc. In the case where the primary and secondary tokens are in the same form, they would be different elements of the same form, such as different files or different directories, since the primary and secondary tokens needs to have separate identities to support the associated functionality. Accordingly, the scope of protection of this invention is limited only by the following claims and their equivalents.

Claims (20)

I claim:
1. A method for managing a shared file system comprising:
establishing a primary token in shared data storage as an element to control access to an object in a shared file system in communication with at least two computer systems in a shared-nothing environment, including a first computer system having a first operating system in communication with a first interface and a second computer system having a second operating system in communication with a second interface, said first operating system different from the second operating system;
each of the first and second interfaces coordinating sharing of an object between an associated operating system and the shared file system;
the first computer system requesting ownership of said primary token through the first interface, including the first interface searching for the primary token in the shared file system, and identifying a prior owner of said primary token;
the first interface receiving a response to said search indicating that said prior owner of said primary token is unavailable; and
creating a secondary token in response to receipt of said response, including the first interface taking ownership of said secondary token and transferring the secondary token to the first computer system, wherein the secondary token is created while the primary token is in existence.
2. The method of claim 1, further comprising broadcasting primary token invalidation information to each server with access to said file system.
3. The method of claim 2, further comprising returning to use of said primary token when it becomes available.
4. The method of claim 3, further comprising releasing and invalidating said secondary token to all servers with access to said file system in conjunction with return of said primary token.
5. The method of claim 1, wherein the step of requesting said primary token from said prior owner includes issuing a heartbeat to said owner of said primary token to determine if said prior owner is in communication with a server requesting said primary token.
6. The method of claim 1, wherein said token is selected from the group consisting of:
a file, a directory, meta data, an attribute of the file system, and an object in the file system.
7. A computer system, comprising:
a shared file system in communication with at least two computer systems in a shared-nothing environment, including a first computer system having a first operating system in communication with a first interface and a second computer system having a second operating system in communication with a second interface, said first operating system different from the second operating system;
each of the first and second interfaces to coordinate sharing of an object between an associated operating system and the shared file system;
a manager associated with one of the first and second computer systems to request ownership of a primary token through the first interface, including the first interface searching for the primary token in the shared file system, and identifying a prior owner of said primary token, said primary token provides control access to an object in said file system;
said manager receives a negative response to said search indicating that said prior owner is unavailable; and
said manager issues a secondary token in response to receipt of said negative response from said prior owner, wherein the first interface takes ownership of said secondary token and transfers the secondary token to the first computer system, wherein the secondary token is created while the primary token is in existence.
8. The system of claim 7, further comprising said manager to broadcast primary token invalidation information to each server with access to said file system.
9. The system of claim 8, further comprising a return to use of said primary token when it becomes available.
10. The system of claim 9, further comprising said manager to release and invalidate said secondary token to all servers with access to said file system in conjunction with return of said primary token.
11. The system of claim 7, wherein the request of said primary token from said prior owner includes issuance of a heartbeat to said owner of said primary token to determine if said prior owner is in communication with a server requesting said primary token.
12. The system of claim 7, wherein said token is selected from the group consisting of:
a file, a directory, meta data, an attribute of the file system, and an object in the file system.
13. An article comprising:
a non-transitory computer readable data storage medium including computer program instructions configured to manage a shared file system comprising:
instructions to establish a primary token in as an element to control access to an object in said shared file system, said file system in communication at least two, computer systems in a shared-nothing environment, including a first computer system having a first operating system in communication with a first interface and a second computer system having a second operating system in communication with a second interface, said first operating system different from the second operating system;
each of the first and second interfaces to coordinate sharing of an object between an associated operating system and the shared file system;
instructions for the first computer system to issue a request for said primary token through the first interface, including the first interface searching for the primary token in the shared file system, and identifying a prior owner of the primary token; and
instructions to issue a secondary token in response to receipt of a response to the search indicating that said server owning said primary token is unavailable, and wherein the first interface taking ownership of said secondary token and transferring the secondary token to the first computer system, wherein the secondary token is created while the primary token is in existence.
14. The article of claim 13, further comprising instructions to broadcast primary token invalidation information to each server with access to said file system.
15. The article of claim 14, further comprising instructions to return to use of said primary token when it becomes available.
16. The article of claim 15, further comprising instructions to release and invalidate said secondary token to all servers with access to said file system in conjunction with return of said primary token.
17. The article of claim 13, wherein the instructions to request said primary token from said prior owner includes instructions to issue a heartbeat to said owner of said primary token to determine if said prior owner is in communication with a server requesting said primary token.
18. The article of claim 13, wherein said token is selected from the group consisting of: a file, a directory, meta data, an attribute of the file system, and an object in the file system.
19. A method for managing a shared file system comprising:
establishing a primary token in shared data storage as an element to control access to an object in a shared file system associated with said storage, said file system in communication at least two, computer systems in a shared-nothing environment, including a first computer system having a first operating system in communication with a first interface and a second computer system having a second operating system in communication with a second interface, said first operating system different from the second operating system;
each of the first and second interfaces coordinate sharing of an object between an associated operating system and the shared file system;
the first computer system requesting ownership of said primary token through the first interface, including the first interface searching for the primary token in the shared file system, and identifying a prior owner of said primary token; and
creating a secondary token in said system in response to the first interface receipt of a negative response to the search, wherein the first interface taking ownership of said secondary token and transferring the secondary token to the first computer system, wherein the secondary token is created while the primary token is in existence.
20. The method of claim 19, wherein said negative response indicates that said prior owner is unavailable.
US11/765,912 2007-06-20 2007-06-20 Distributed lock manager for file system objects in a shared file system Expired - Fee Related US8990954B2 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US11/765,912 US8990954B2 (en) 2007-06-20 2007-06-20 Distributed lock manager for file system objects in a shared file system
CNA2008101102172A CN101329681A (en) 2007-06-20 2008-06-18 Distributed lock manager for file system objects in a shared file system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US11/765,912 US8990954B2 (en) 2007-06-20 2007-06-20 Distributed lock manager for file system objects in a shared file system

Publications (2)

Publication Number Publication Date
US20080319996A1 US20080319996A1 (en) 2008-12-25
US8990954B2 true US8990954B2 (en) 2015-03-24

Family

ID=40137577

Family Applications (1)

Application Number Title Priority Date Filing Date
US11/765,912 Expired - Fee Related US8990954B2 (en) 2007-06-20 2007-06-20 Distributed lock manager for file system objects in a shared file system

Country Status (2)

Country Link
US (1) US8990954B2 (en)
CN (1) CN101329681A (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150113010A1 (en) * 2013-10-23 2015-04-23 Netapp, Inc. Distributed file system gateway
US9507800B2 (en) 2013-10-23 2016-11-29 Netapp, Inc. Data management in distributed file systems
CN106713250A (en) * 2015-11-18 2017-05-24 杭州华为数字技术有限公司 Data access method and device based on distributed system
US10296469B1 (en) * 2014-07-24 2019-05-21 Pure Storage, Inc. Access control in a flash storage system

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB0908041D0 (en) * 2009-05-11 2009-06-24 True Blue Logic Ltd Improvements in and relating to replicated file servers
US20120102314A1 (en) * 2010-04-01 2012-04-26 Huizhou TCL Mobile Communications Co., Ltd. Smart phone system and booting method thereof
KR101755421B1 (en) * 2011-01-10 2017-07-10 삼성전자주식회사 Method and system for editing file information system of host device using client device
US8533796B1 (en) * 2011-03-16 2013-09-10 Google Inc. Providing application programs with access to secured resources
CN102142032B (en) * 2011-03-28 2013-03-20 中国人民解放军国防科学技术大学 Method and system for reading and writing data of distributed file system
WO2012140671A2 (en) * 2011-04-11 2012-10-18 Ineda Systems Pvt. Ltd File system sharing
US8924370B2 (en) 2011-05-31 2014-12-30 Ori Software Development Ltd. Efficient distributed lock manager
EP3059932B1 (en) * 2014-11-12 2018-09-19 Huawei Technologies Co., Ltd. Lock server malfunction processing method and system thereof in distribution system
CN106202074B (en) * 2015-04-29 2021-02-23 中兴通讯股份有限公司 Method and device for processing shared file
AU2015408848B2 (en) 2015-12-30 2018-10-18 Huawei Technologies Co., Ltd Method for processing acquire lock request and server
CN107122410A (en) * 2017-03-29 2017-09-01 武汉斗鱼网络科技有限公司 A kind of buffering updating method and device

Citations (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0450917A2 (en) 1990-04-04 1991-10-09 International Business Machines Corporation Distributed computer systems
US5202971A (en) * 1987-02-13 1993-04-13 International Business Machines Corporation System for file and record locking between nodes in a distributed data processing environment maintaining one copy of each file lock
US5454108A (en) * 1994-01-26 1995-09-26 International Business Machines Corporation Distributed lock manager using a passive, state-full control-server
US5535375A (en) * 1992-04-20 1996-07-09 International Business Machines Corporation File manager for files shared by heterogeneous clients
US5566297A (en) * 1994-06-16 1996-10-15 International Business Machines Corporation Non-disruptive recovery from file server failure in a highly available file system for clustered computing environments
US5634122A (en) * 1994-12-30 1997-05-27 International Business Machines Corporation System and method for multi-level token management for distributed file systems
JPH09223032A (en) 1996-02-19 1997-08-26 Fujitsu Ltd Resources lock control mechanism
US5893086A (en) * 1997-07-11 1999-04-06 International Business Machines Corporation Parallel file system and method with extensible hashing
JP2000020324A (en) 1998-06-30 2000-01-21 Yokogawa Electric Corp Distributed agent system
US6023706A (en) * 1997-07-11 2000-02-08 International Business Machines Corporation Parallel file system and method for multiple node file access
US6032216A (en) * 1997-07-11 2000-02-29 International Business Machines Corporation Parallel file system with method using tokens for locking modes
US6041383A (en) * 1996-07-22 2000-03-21 Cabletron Systems, Inc. Establishing control of lock token for shared objects upon approval messages from all other processes
US6389420B1 (en) 1999-09-30 2002-05-14 Emc Corporation File manager providing distributed locking and metadata management for shared data access by clients relinquishing locks after time period expiration
US20020188590A1 (en) * 2001-06-06 2002-12-12 International Business Machines Corporation Program support for disk fencing in a shared disk parallel file system across storage area network
US20030018785A1 (en) 2001-07-17 2003-01-23 International Business Machines Corporation Distributed locking protocol with asynchronous token prefetch and relinquish
US6539446B1 (en) * 1999-05-07 2003-03-25 Oracle Corporation Resource locking approach
US20040066741A1 (en) * 2002-09-23 2004-04-08 Darpan Dinker System and method for performing a cluster topology self-healing process in a distributed data system cluster
US20040215772A1 (en) * 2003-04-08 2004-10-28 Sun Microsystems, Inc. Distributed token manager with transactional properties
US20040221079A1 (en) * 2001-11-13 2004-11-04 Microsoft Corporation Method and system for locking multiple resources in a distributed environment
US20040230877A1 (en) * 2003-04-29 2004-11-18 Interantional Business Machines Corporation Automatically freezing functionality of a computing entity responsive to an error
US20050273529A1 (en) * 2004-05-20 2005-12-08 Young Jason C Fencing of resources allocated to non-cooperative client computers
US20070027872A1 (en) * 2005-07-28 2007-02-01 Microsoft Corporation Resource handling for taking permissions
US20070180517A1 (en) * 2004-03-04 2007-08-02 Alain Rhelimi Secure sharing of resources between applications in independent execution environments in a retrievable token (e.g. smart card)
US20080168458A1 (en) * 2007-01-05 2008-07-10 Fachan Neal T Systems and methods for managing semantic locks
US7409389B2 (en) * 2003-04-29 2008-08-05 International Business Machines Corporation Managing access to objects of a computing environment
US7418500B1 (en) * 2002-03-25 2008-08-26 Network Appliance, Inc. Mechanism for controlled sharing of files in a clustered application environment
US7475199B1 (en) * 2000-10-19 2009-01-06 Emc Corporation Scalable network file system
US7596563B1 (en) * 1999-10-28 2009-09-29 Hewlett-Packard Development Company, L.P. Computerized file system and method
US7698708B1 (en) * 2004-07-30 2010-04-13 Symantec Operating Corporation Method and system for persistent, recoverable user-level locks
US7788716B2 (en) * 2004-05-21 2010-08-31 Bea Systems, Inc. Token handler API
US8495266B2 (en) * 2004-12-10 2013-07-23 Hewlett-Packard Development Company, L.P. Distributed lock
US8560747B1 (en) * 2007-02-16 2013-10-15 Vmware, Inc. Associating heartbeat data with access to shared resources of a computer system

Patent Citations (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5202971A (en) * 1987-02-13 1993-04-13 International Business Machines Corporation System for file and record locking between nodes in a distributed data processing environment maintaining one copy of each file lock
EP0450917A2 (en) 1990-04-04 1991-10-09 International Business Machines Corporation Distributed computer systems
JPH05210637A (en) 1990-04-04 1993-08-20 Internatl Business Mach Corp <Ibm> Method of simultaneously controlling access
US5535375A (en) * 1992-04-20 1996-07-09 International Business Machines Corporation File manager for files shared by heterogeneous clients
US5454108A (en) * 1994-01-26 1995-09-26 International Business Machines Corporation Distributed lock manager using a passive, state-full control-server
US5566297A (en) * 1994-06-16 1996-10-15 International Business Machines Corporation Non-disruptive recovery from file server failure in a highly available file system for clustered computing environments
US5634122A (en) * 1994-12-30 1997-05-27 International Business Machines Corporation System and method for multi-level token management for distributed file systems
JPH09223032A (en) 1996-02-19 1997-08-26 Fujitsu Ltd Resources lock control mechanism
US6041383A (en) * 1996-07-22 2000-03-21 Cabletron Systems, Inc. Establishing control of lock token for shared objects upon approval messages from all other processes
US5893086A (en) * 1997-07-11 1999-04-06 International Business Machines Corporation Parallel file system and method with extensible hashing
US6023706A (en) * 1997-07-11 2000-02-08 International Business Machines Corporation Parallel file system and method for multiple node file access
US6032216A (en) * 1997-07-11 2000-02-29 International Business Machines Corporation Parallel file system with method using tokens for locking modes
JP2000020324A (en) 1998-06-30 2000-01-21 Yokogawa Electric Corp Distributed agent system
US6539446B1 (en) * 1999-05-07 2003-03-25 Oracle Corporation Resource locking approach
US6389420B1 (en) 1999-09-30 2002-05-14 Emc Corporation File manager providing distributed locking and metadata management for shared data access by clients relinquishing locks after time period expiration
US7596563B1 (en) * 1999-10-28 2009-09-29 Hewlett-Packard Development Company, L.P. Computerized file system and method
US7475199B1 (en) * 2000-10-19 2009-01-06 Emc Corporation Scalable network file system
US20020188590A1 (en) * 2001-06-06 2002-12-12 International Business Machines Corporation Program support for disk fencing in a shared disk parallel file system across storage area network
US20030018785A1 (en) 2001-07-17 2003-01-23 International Business Machines Corporation Distributed locking protocol with asynchronous token prefetch and relinquish
US20040221079A1 (en) * 2001-11-13 2004-11-04 Microsoft Corporation Method and system for locking multiple resources in a distributed environment
US20060136637A1 (en) * 2001-11-13 2006-06-22 Microsoft Corporation Locking multiple resources in a distributed environment
US7418500B1 (en) * 2002-03-25 2008-08-26 Network Appliance, Inc. Mechanism for controlled sharing of files in a clustered application environment
US20040066741A1 (en) * 2002-09-23 2004-04-08 Darpan Dinker System and method for performing a cluster topology self-healing process in a distributed data system cluster
US20040215772A1 (en) * 2003-04-08 2004-10-28 Sun Microsystems, Inc. Distributed token manager with transactional properties
US7409389B2 (en) * 2003-04-29 2008-08-05 International Business Machines Corporation Managing access to objects of a computing environment
US20040230877A1 (en) * 2003-04-29 2004-11-18 Interantional Business Machines Corporation Automatically freezing functionality of a computing entity responsive to an error
US8700584B2 (en) * 2003-04-29 2014-04-15 International Business Machines Corporation Managing access to objects of a computing environment
US20070180517A1 (en) * 2004-03-04 2007-08-02 Alain Rhelimi Secure sharing of resources between applications in independent execution environments in a retrievable token (e.g. smart card)
US20050273529A1 (en) * 2004-05-20 2005-12-08 Young Jason C Fencing of resources allocated to non-cooperative client computers
US7788716B2 (en) * 2004-05-21 2010-08-31 Bea Systems, Inc. Token handler API
US7698708B1 (en) * 2004-07-30 2010-04-13 Symantec Operating Corporation Method and system for persistent, recoverable user-level locks
US8495266B2 (en) * 2004-12-10 2013-07-23 Hewlett-Packard Development Company, L.P. Distributed lock
US20070027872A1 (en) * 2005-07-28 2007-02-01 Microsoft Corporation Resource handling for taking permissions
US20080168458A1 (en) * 2007-01-05 2008-07-10 Fachan Neal T Systems and methods for managing semantic locks
US8560747B1 (en) * 2007-02-16 2013-10-15 Vmware, Inc. Associating heartbeat data with access to shared resources of a computer system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Ciuffoletti, "The Wandering Token: Congestion Avoidance of a Shared Resource," Technical Report TR-05-13, University of Pisa, May 2005, 17 pages. *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150113010A1 (en) * 2013-10-23 2015-04-23 Netapp, Inc. Distributed file system gateway
US9507800B2 (en) 2013-10-23 2016-11-29 Netapp, Inc. Data management in distributed file systems
US9575974B2 (en) * 2013-10-23 2017-02-21 Netapp, Inc. Distributed file system gateway
US10296469B1 (en) * 2014-07-24 2019-05-21 Pure Storage, Inc. Access control in a flash storage system
US10348675B1 (en) 2014-07-24 2019-07-09 Pure Storage, Inc. Distributed management of a storage system
CN106713250A (en) * 2015-11-18 2017-05-24 杭州华为数字技术有限公司 Data access method and device based on distributed system
CN106713250B (en) * 2015-11-18 2019-08-20 杭州华为数字技术有限公司 Data access method and device based on distributed system

Also Published As

Publication number Publication date
CN101329681A (en) 2008-12-24
US20080319996A1 (en) 2008-12-25

Similar Documents

Publication Publication Date Title
US8990954B2 (en) Distributed lock manager for file system objects in a shared file system
US9400829B2 (en) Efficient distributed lock manager
US7315926B2 (en) Lock management for concurrent access to a single file from multiple data mover computers
US8346719B2 (en) Multi-node replication systems, devices and methods
US7991822B2 (en) Propagation of updates for attributes of a storage object from an owner node of the storage object to other nodes
US6389420B1 (en) File manager providing distributed locking and metadata management for shared data access by clients relinquishing locks after time period expiration
US5339427A (en) Method and apparatus for distributed locking of shared data, employing a central coupling facility
US7774568B2 (en) Clustered snapshots in networks
US7899895B2 (en) Transfer of ownership of a storage object in response to an original owner node becoming available after a period of unavailability
US7778986B2 (en) Securing transfer of ownership of a storage object from an unavailable owner node to another node
US20070143340A1 (en) System and method of time-based cache coherency maintenance in user file manager of object-based storage system
JPH07219792A (en) Equipment and method for lock
US5832501A (en) Method and system for filtering file manager attribute values
GB2504109A (en) Combining scalability across multiple resources in a transaction processing system having global serializability.
JP2009294695A (en) Transaction parallel control method, database management system, and program
US7574439B2 (en) Managing a nested request
TWI226549B (en) High-performance lock management for flash copy in n-way shared storage systems
US7444349B1 (en) Control of concurrent access to a partitioned data file
US11449241B2 (en) Customizable lock management for distributed resources
US10055139B1 (en) Optimized layout in a two tier storage
CN110659303A (en) Read-write control method and device for database nodes
US11416441B2 (en) RPC-less locking mechanism based on RDMA CAW for storage cluster with active-active architecture
US11216439B2 (en) Auto-expiring locks based on object stamping
US11366594B2 (en) In-band extent locking
US6834281B1 (en) Method and apparatus to support multi-node direct access to file system data

Legal Events

Date Code Title Description
AS Assignment

Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:COOK, STEVEN D.;REEL/FRAME:019877/0346

Effective date: 20070620

STCF Information on status: patent grant

Free format text: PATENTED CASE

FEPP Fee payment procedure

Free format text: MAINTENANCE FEE REMINDER MAILED (ORIGINAL EVENT CODE: REM.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

LAPS Lapse for failure to pay maintenance fees

Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

STCH Information on status: patent discontinuation

Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362

FP Expired due to failure to pay maintenance fee

Effective date: 20190324