EFFICIENT FILE MANAGEMENT THROUGH GRANULAR OPPORTUNISTIC LOCKING

• US 20150229735A1
• Filed: 04/23/2015
• Published: 08/13/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.
• Granted Patent: US 9,654,585 B2
• Time in Patent Office: Days
• 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, comprising:

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

granting a first oplock state as specified by a first client request as any combination of caching intentions; and

transitioning from the first oplock state as specified to a second oplock state upon receiving an acknowledgement that the first oplock state is broken.

2. The method of claim 1, opening the file handle with an oplock key associated to the first client comprising:

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 method of claim 1, the oplock key identifies a client and prevents two or more file handles from the client from breaking each other'"'"'s oplock state.

4. The method of claim 1, comprising:

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

providing an opportunity for the client to flush any unwritten data to the server, re-open any handles which 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.

5. The method of claim 1, where the first oplock state as specified by the first client request is not confined to any particular combination of caching intentions comprising:

read caching, write caching, and/or handle caching.

6. The method of claim 2, where 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 therebetween.

7. The method of claim 1, where the second oplock state specifies a higher caching level than the first oplock state so that the second oplock state has been upgraded relative to the first oplock state instead of downgraded.

8. The method of claim 1, comprising:

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

performing the share check for a second time; and

upon discovery of a sharing violation, failing any file open requests.

9. The method of claim 1, comprising:

breaking the first oplock state when a second client makes an incompatible request on the file handle associated with a different oplock key from the one that was used to acquire the file handle by the first client.

10. A file server comprising:

a storage having a file directed for shared usage;

an interface to a network; and

a processor, the storage operating from control signals of the processor to enforce opportunistic locking semantics for accessing the storage across the network, the opportunistic locking semantics enforced among the plurality of clients, the processor configured to;

open a file handle of the file directed for shared usage with an oplock key associating a first client to the file handle;

grant a first oplock state as specified by a first client request as any combination of caching intentions; and

transition from the first oplock state as specified to a second oplock state upon receiving an acknowledgement that the first oplock state is broken.

11. The file server of claim 10, opening the file handle with an oplock key associating the first client to the file handle comprising:

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.

12. The file server of claim 10, the oplock key identifies a client and prevents two or more file handles from the client from breaking each other'"'"'s oplock state.

13. The file server of claim 10, the processor configured to:

notify the first client of the first client request that the first oplock state is broken upon receiving a second client request when the second client request is specified without an oplock key being substantially identical to the oplock key associated to the file handle originally opened; and

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

14. The file server of claim 10, where the first oplock state as specified by the first client request is not confined to any particular combination of caching intentions comprising:

read caching, write caching, and/or handle caching.

15. The file server of claim 11, where 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 therebetween.

16. The file server of claim 10, where the second oplock state specifies a higher caching level than the first oplock state so that the second oplock state has been upgraded relative to the first oplock state instead of downgraded.

17. The file server of claim 10, performing a share check before breaking the first oplock state.

18. The file server of claim 10, comprising:

breaking the first oplock state when a second client makes an incompatible request on the file handle with a different oplock key from the one that was used to acquire the file handle by the first client.

19. A method for allocating and managing files in a multi-user network environment having at least one server with a file directed for shared usage, comprising:

opening a file handle with an oplock key associated to a first client and prevents two or more file handles from the first client from breaking each other'"'"'s oplock state;

granting a first oplock state as specified by a first client request as any combination of caching intentions comprising;

read caching, write caching, and/or handle caching; and

transitioning from the first oplock state as specified to a second oplock state upon receiving an acknowledgement that the first oplock state is broken comprising;

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

providing an opportunity for the client to flush any unwritten data to the server, re-open any handles which were collapsed on the client, close any cached handles and purge its read cache;

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

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

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 19, opening the file handle with an oplock key associated to the first client comprising:

checking for oplocks on the file handle;

creating the file handle with an atomic oplock flag that 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 therebetween;

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;

where the second oplock state specifies a higher caching level than the first oplock state so that the second oplock state has been upgraded relative to the first oplock state instead of downgraded.