Efficient file management through granular opportunistic locking

• US 9,047,281 B2
• Filed: 12/30/2011
• Issued: 06/02/2015
• Est. Priority Date: 06/26/2008
• Status: Active Grant

• Current Assignee: Microsoft Technology Licensing LLC (Microsoft Corporation)
• Original Assignee: Microsoft Technology Licensing LLC (Microsoft Corporation)
• Inventors: Rajaram, Senthil, Christiansen, Neal R., Allred, Christian G., Kruse, David M., George, Mathew, Kirubanandan, Nandagopal, Havewala, Sarosh C.
• Primary Examiner(s): Pezzlo, John
• Application Number:
  US13/341,169
• Publication Number:
  US 20120102272A1
• Time in Patent Office: 1,250 Days
• Field of Search: 370/282, 370/241, 370/252, 370/419, 370/412
• US Class Current: 1/1
• CPC Class Codes: G06F 12/0891 using clearing, invalidating or resetting means
• CPC Class Codes: G06F 16/10 File systems; File servers
• CPC Class Codes: G06F 16/1774 Locking methods, e.g. locking methods for file systems allowing shared and concurrent access to files
• CPC Class Codes: G06F 16/182 Distributed file systems
• CPC Class Codes: G06F 16/2308 Concurrency control transaction processing G06F9/466
• CPC Class Codes: G06F 16/2343 Locking methods, e.g. distributed locking or locking implementation details
• CPC Class Codes: G06F 16/27 Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
• CPC Class Codes: G06F 16/951 Indexing; Web crawling techniques
• CPC Class Codes: G06F 2212/6042 Allocation of cache space to multiple users or processors
• CPC Class Codes: H04L 67/5682 Policies or rules for updating, deleting or replacing the stored data

Abstract

Improved methods and systems for granular opportunistic locking mechanisms (oplocks) are provided for increasing file caching efficiency. Oplocks can be specified with a combination of three possible granular caching intentions: read, write, and/or handle. An oplock can be specified with an identifier that indicates a client/specific caller to avoid breaking the original oplock due to an incompatibility from other requests of the same client. An atomic oplock flag is added to create operations that allow callers to request an atomic open with an oplock with a given file.

Claims

1. A method for maintaining distributed cache coherency across multiple clients accessing a file or a shared resource, the method comprising:

associating an oplock key with a first client, wherein the oplock key includes a file handle;

transmitting an oplock state request from the first client, the request indicating that the first client is locally caching one or more of;

(i) write data, (ii) read data, and (iii) the file handle;

receiving the requested oplock state;

requesting a second oplock state in response to determining that the first oplock state is broken; and

transitioning from the first oplock state to the second oplock state.

2. The method of claim 1, wherein the second oplock state is different from the first oplock state.

3. The method of claim 1, wherein the second oplock state is the same as the first oplock state.

4. The method of claim 1, wherein determining that the first oplock state is broken comprises determining whether an open request associated with a file has the same oplock key as the first oplock state.

5. The method of claim 1, wherein determining that the first oplock state is broken comprises determining whether a transition was made from the first oplock state to a state of lesser caching.

6. The method of claim 1, further comprising sending an acknowledgement that the first oplock state is broken.

7. The method of claim 6, further comprising sending an indication of a level at which the first oplock state is broken.

8. A computer-readable storage device encoding computer executable instructions that, when executed by at least one processor, performs a method for maintaining distributed cache coherency across multiple clients accessing a file or a shared resource, the method comprising:

associating an oplock key with a first client, wherein the oplock key includes a file handle;

transmitting an oplock state request from the first client, the request indicating that the first client is locally caching one or more of;

(i) write data, (ii) read data, and (iii) the file handle;

receiving the requested oplock state;

in response to determining that the first oplock state is broken, requesting a second oplock state; and

transitioning from the first oplock state to the second oplock state.

9. The computer-readable storage device of claim 8, wherein the second oplock state is different from the first oplock state.

10. The computer-readable storage device of claim 8, wherein the second oplock state is the same as the first oplock state.

11. The computer-readable storage device of claim 8, wherein determining that the first oplock state is broken comprises determining whether an open request associated with a file has the same oplock key as the first oplock state.

12. The computer-readable storage device of claim 8, wherein determining that the first oplock state is broken comprises determining whether a transition was made from the first oplock state to a state of lesser caching.

13. The computer-readable storage device of claim 8, further comprising sending an acknowledgement that the first oplock state is broken.

14. The computer-readable storage device of claim 13, further comprising sending an indication of a level at which the first oplock state is broken.

15. A computer system comprising:

one or more processors; and

a memory coupled to the one or more processors, the memory for storing instructions which, when executed by the one or more processors, cause the one or more processors to perform a method for maintaining distributed cache coherency across multiple clients accessing a file or a shared resource, the method comprising;

associating an oplock key with a first client, wherein the oplock key includes a file handle;

transmitting an oplock state request from the first client, the request indicating that the first client is locally caching one or more of;

(i) write data, (ii) read data, and (iii) the file handle;

receiving the requested oplock state;

in response to determining that the first oplock state is broken, requesting a second oplock state; and

transitioning from the first oplock state to the second oplock state.

16. The system of claim 15, wherein the second oplock state is different from the first oplock state.

17. The system of claim 15, wherein determining that the first oplock state is broken comprises determining whether an open request associated with a file has the same oplock key as the first oplock state.

18. The system of claim 15, wherein determining that the first oplock state is broken comprises determining whether a transition was made from the first oplock state to a state of lesser caching.

19. The system of claim 15, further comprising instructions for sending an acknowledgement that the first oplock state is broken.

20. The system of claim 15, further comprising instructions for sending an indication of a level at which the first oplock state is broken.