Efficient file management through granular opportunistic locking

• US 9,654,585 B2
• Filed: 04/23/2015
• Issued: 05/16/2017
• 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: George, Mathew, Havewala, Sarosh C., Christiansen, Neal R., Kruse, David M., Rajaram, Senthil, Allred, Christian G., Kirubanandan, Nandagopal
• Primary Examiner(s): Pezzlo, John
• Application Number:
  US14/694,640
• Publication Number:
  US 20150229735A1
• Time in Patent Office: 754 Days
• Field of Search: 370252, 370282, 370412, 370419
• 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 system comprising:

at least one processor;

a memory, operatively connected to the at least one processor and including instructions that, when executed by the at least one processor, cause the at least one processor to perform a method, the method comprising;

receiving a request from a first client, the request indicating an intent to locally cache one or more of;

write data, read data, and a file handle;

opening the file with a file handle and an oplock key associated to the first client;

granting a first oplock state to the first client; and

in response to receiving an acknowledgement that the first oplock state is broken, transitioning from the first oplock state by granting the first client a second oplock state that is different from the first oplock state.

2. The system of claim 1, wherein opening the file with the file handle and the oplock key associated to the first client comprises:

checking for oplocks on the file handle;

creating the file handle with an atomic oplock flag;

placing a temporary oplock on the file handle; and

upon an unsuccessful request by a second client, returning with an await status signifying that the temporary oplock is not able to be broken and allowing for the unsuccessful request by the second client to be retried, or blocking the second client'"'"'s request thereafter.

3. The system of claim 2, wherein the atomic oplock flag prevents breaking of the first oplock state between a time when the first client opens the file and when the first oplock state is specified by placing a temporary oplock on the file.

4. The system of claim 1, wherein the oplock key identifies the first client and prevents two or more file handles from the first client from breaking each other'"'"'s oplock state.

5. The system of claim 1, the method further comprising:

notifying the first client of the first client request that the first oplock state is broken upon receiving a second client request without the oplock key associated to the file handle originally opened;

providing an opportunity for the first client to flush any unwritten data to the server, reopen any handles that were collapsed on the client, close any cached handles and purge its read cache; and

transmitting the oplock key to a file system control and storing the oplock key.

6. The system of claim 1, wherein the second oplock state specifies a higher caching level than the first oplock state.

7. The system of claim 1, the method further comprising:

performing a share check to determine a sharing violation, and upon discovering a sharing violation breaking existing handle oplocks; and

performing the share check for a second time, and upon discovery of a sharing violation, failing any file open requests.

8. The system of claim 1, the method further comprising:

breaking the first oplock state when a second client makes an incompatible request on the file handle associated with a different oplock key.

9. A system comprising:

at least one processor;

a memory, operatively connected to the at least one processor and including instructions that, when executed by the at least one processor, cause the at least one processor to perform a method, the method comprising;

receiving a request from a first client, the request indicating an intent to locally cache one or more of;

write data, read data, and a file handle;

opening the file with a file handle and an oplock key associated to the first client;

granting a first oplock state to the first client; and

in response to receiving a request from a second client with a second oplock key associated to the second client, transitioning from the first oplock state by granting the first client a second oplock state that is different from the first oplock state.

10. The system of claim 9, wherein the oplock key identifies the first client and prevents two or more file handles from the first client from breaking each other'"'"'s oplock state.

11. The system of claim 9, the method further comprising:

breaking the first oplock state when the second client makes an incompatible request on the file handle associated with the second oplock key.

12. The system of claim 9, wherein the second oplock state specifies a lower caching level than the first oplock state.

13. A method comprising:

receiving a request from a first client, the request indicating an intent to locally cache one or more of;

write data, read data, and a file handle;

opening a file with a file handle and an oplock key associated to the first client;

granting a first oplock state to the first client; and

in response to receiving an acknowledgement that the first oplock state is broken, transitioning from the first oplock state by granting the first client a second oplock state that is different from the first oplock state.

14. The method of claim 13, wherein opening the file with the file handle and the oplock key associated to the first client comprises:

checking for oplocks on the file handle;

creating the file handle with an atomic oplock flag;

placing a temporary oplock on the file handle; and

upon an unsuccessful request by a second client, returning with an await status signifying that the temporary oplock is not able to be broken and allowing for the unsuccessful request by the second client to be retried, or blocking the second client'"'"'s request thereafter.

15. The method of claim 14, wherein the atomic oplock flag prevents breaking of the first oplock state between a time when the first client opens the file and when the first oplock state is specified by placing a temporary oplock on the file.

16. The method of claim 13, wherein the oplock key identifies the first client and prevents two or more file handles from the first client from breaking each other'"'"'s oplock state.

17. The method of claim 13, further comprising:

notifying the first client of the first client request that the first oplock state is broken upon receiving a second client request without the oplock key associated to the file handle originally opened;

providing an opportunity for the first client to flush any unwritten data to the server, reopen any handles that were collapsed on the client, close any cached handles and purge its read cache; and

transmitting the oplock key to a file system control and storing the oplock key.

18. The method of claim 13, wherein the second oplock state specifies a higher caching level than the first oplock.

19. The method of claim 13, further comprising:

performing a share check to determine a sharing violation, and upon discovering a sharing violation breaking existing handle oplocks; and

performing the share check for a second time, and upon discovery of a sharing violation, failing any file open requests.

20. The method of claim 13, further comprising:

breaking the first oplock state when a second client makes an incompatible request on the file handle associated with a different oplock key.