Optimistic locking method and system for committing transactions on a file system

• US 8,700,585 B2
• Filed: 11/26/2008
• Issued: 04/15/2014
• Est. Priority Date: 02/06/2004
• Status: Active Grant

• Current Assignee: Vmware LLC (Broadcom, Inc.)
• Original Assignee: VMware, Inc. (Broadcom, Inc.)
• Inventors: Vaghani, Satyam B., Tan, Yuen-Lin
• Primary Examiner(s): Perveen, Rehana
• Assistant Examiner(s): Hershley, Mark E
• Application Number:
  US12/324,665
• Publication Number:
  US 20090106248A1
• Time in Patent Office: 1,966 Days
• Field of Search: 707/704, 707/781, 707/782, 707/783
• US Class Current: 707/704
• CPC Class Codes: G06F 16/1767 Concurrency control, e.g. optimistic or pessimistic approaches

Abstract

In a file system shared by multiple servers, reservation of a data storage unit such as a LUN of a disk array to acquire locks in order to commit a transaction acting on data stored in the data storage unit is deferred until the transaction is completed in RAM and the locks can be acquired in parallel during a single instance of reserving the data storage unit.

Claims

1. In a shared file system that is accessible by a group of servers, wherein the shared file system resides in a data storage unit having a logical storage space that is contiguous and maps to physical storage space of a shared storage array, a method for committing a transaction acting upon data stored in the logical storage space of said data storage unit, the method being carried out by a server in said group and comprising:

reading a state of a set of locks relating to the data from the data storage unit, wherein the data and data fields of the locks relating to the data are stored in the logical storage space of the data storage unit;

constructing a completed transaction in memory of said server prior to acquiring the locks;

after said constructing, acquiring exclusive possession of the data storage unit, wherein said acquiring prevents other servers in the group from accessing the logical storage space of the data storage unit;

while having exclusive possession of the data storage unit, acquiring the locks if the state of the locks has not changed since said reading; and

committing the completed transaction,

where said acquiring the locks includes writing a unique identifier associated with said server into one of the data fields of each of the locks.

2. The method of claim 1, further comprising:

journaling the completed transaction to the data storage unit prior to said committing.

3. The method of claim 1, wherein each of the locks has a version data field that is incremented upon said lock'"'"'s acquisition or release and determining that the state of a lock has changed if the version data field of the lock has changed.

4. The method of claim 1, wherein said acquiring exclusive possession of the data storage unit step uses a SCSI (Small Computer System Interface) reservation command.

5. The method of claim 4, wherein said acquiring the locks occurs using SCSI (Small Computer System Interface) pipelined commands.

6. The method of claim 1, wherein the completed transaction in memory comprises a data structure comprising a record of locks relating to the data and a record of updates to be performed on said data.

7. The method of claim 1, further comprising:

adding pre-commit actions to a pre-commit actions buffer of the completed transaction; and

executing the pre-commit actions after said acquiring the locks and before said committing the completed transaction.

8. The method of claim 1, wherein the data is metadata for a file.

9. The method of claim 1, wherein the data storage unit is a logical data storage unit exposed by a controller of the shared storage array.

10. The method of claim 1, further comprising:

checking a retry counter if the state of the locks has changed; and

re-performing said method if the retry counter is greater than zero.

11. The method of claim 10, wherein the retry counter relates to the transaction.

12. The method of claim 10, wherein the retry counter relates to a context corresponding to the transaction.

13. A computer system with a shared file system accessed by a plurality of servers, the computer system comprising:

a plurality of servers, wherein each of the servers comprises a processor, a random access memory (RAM) and an operating system accessing the shared file system; and

a shared storage array coupled to the plurality of servers, wherein the shared storage array comprises a controller that exposes to the servers a data storage unit in which the shared file system is stored, the data storage unit having a logical storage space that is contiguous and maps to physical storage space of the shared storage array,

wherein each server'"'"'s processor is programmed to perform the following steps to commit a transaction for a process running on said server;

reading a first state of a set of locks relating to data to be acted upon by the transaction from the data storage unit, wherein the data and data fields of the locks relating to the data are stored in the logical storage space of the data storage unit;

constructing a completed version of the transaction in said server'"'"'s RAM prior to acquiring the locks;

after said constructing, acquiring exclusive possession of the data storage unit, wherein said acquiring prevents other servers coupled to the shared storage array from accessing the logical storage space of the data storage unit;

while having exclusive possession of the data storage unit, checking if the locks have changed state since the first state, and acquiring the locks if the state of the locks has not changed since the first state; and

committing the completed transaction to a journal in the data storage unit,

wherein said acquiring the locks includes writing a unique identifier associated with said server into one of the data fields of each of the locks.

14. The computer system of claim 13, wherein the shared storage array is a disk array and is coupled to the plurality of servers through a storage area network (SAN).

15. The computer system of claim 13, wherein each of the servers is further configured to instantiate virtual machines.

16. A non-transitory computer readable storage medium having stored therein a computer program for causing a server to commit a transaction acting upon data stored in a data storage unit having a logical storage space that is contiguous, maps to physical storage space of a shared storage array, and is accessible by said server and other servers, wherein said server executing the computer program carries out:

reading a state of a set of locks relating to the data from the data storage unit, wherein the data and data fields of the locks relating to the data are stored in the logical storage space of the data storage unit;

constructing a completed transaction in memory prior to acquiring the locks;

after said constructing, acquiring exclusive possession of the data storage unit, wherein said acquiring prevents the other servers from accessing the logical storage space of the data storage unit;

while having exclusive possession of the data storage unit, acquiring the locks if the state of the locks has not changed since said reading; and

committing the completed transaction,

wherein said acquiring the locks includes writing a unique identifier associated with said server into one of the data fields of each of the locks.

17. The non-transitory computer readable storage medium of claim 16, wherein said server executing the computer program further carries out journaling the completed transaction to the data storage unit prior to said committing.

18. The non-transitory computer readable storage medium of claim 16, wherein said server executing the computer program further carries out:

adding pre-commit actions to a pre-commit actions buffer of the completed transaction; and

executing the pre-commit actions after the step of acquiring the locks and before the step of committing the completed transaction.

19. The non-transitory computer readable storage medium of claim 16, wherein said server executing the computer program further carries out:

checking a retry counter if the state of the locks has changed; and

re-executing the steps if the retry counter is greater than zero.

20. The non-transitory computer readable storage medium of claim 16, wherein each of the locks has a version data field that is incremented upon said lock'"'"'s acquisition or release and determining that the state of a lock has changed if the version data field of the lock has changed.