HK1165052B - Directory oplock - Google Patents

Description

Directory oplock

Background

Oplocks ("oplocks") are used by file systems to provide clients, such as local and/or remote applications, with the ability to cache file data while providing a mechanism to promote data consistency when multiple clients read/write the same file. In addition, oplocks provide an application the ability to "back off" from when the file is accessed so that the application does not interfere with the access of other applications to the file. In one example, a first application may negotiate an oplock for a text file stored on a file system. The first application may locally cache data corresponding to the text file to reduce network traffic and/or access requests when accessing such data (e.g., multiple writes may be performed locally to the cached data). If the second application attempts to access the text file on the file system, the file system may unlock the oplock by sending a notification to the first application to update the changes to the text file back to the file system. In this way, the text file may be consistent between the first application, the second application, and the file system. Unfortunately, oplocks are currently available for files, but not for directories (directory). Thus, if a first application locally caches directory content from a file system and a second application changes a directory on the file system, the directory content locally cached by the first application may be old (stale) because the first application is not notified of the second application's changes to the directory.

Disclosure of Invention

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key factors or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

Among other things, one or more systems and/or techniques for managing directory oplocks are disclosed herein. A directory oplock may be interpreted as an oplock on a directory (e.g., a folder, a mapped disk drive, a directory located on a remote server, etc.). An oplock request for a directory oplock on a directory may be received from a client (e.g., a file management application, a "save as" dialog box, a search indexer service, a virus scanner, and/or other client). It is to be appreciated that in one example, a client can be interpreted as including one or more applications (e.g., a device on which a directory resides) executing locally (e.g., on the same device, such as a laptop, desktop, etc.) or remotely (e.g., on a different/separate device, such as a server, etc.) in relation to the directory. The oplock request may include a first target key and a first parent key. The first target key may specify a unique identifier corresponding to the directory and the client requesting the directory oplock. The first parent key may specify a unique identifier corresponding to a parent directory that includes the directory and a client that requested the directory oplock. A directory oplock key may be generated based on the oplock request.

A client requesting and being granted a directory oplock may locally cache the directory contents of a directory (e.g., directory metadata, a list of files and subdirectories in the directory, etc.). It can be appreciated that network traffic can be reduced, for example, because a client can perform I/O operations on locally cached directory content without having to directly access the directory over the network. Similarly, by allowing a client (e.g., a local application) to cache its own copy of the directory, the number of access requests may be reduced. In this way, the client may assume that the locally cached directory content is up-to-date. Additionally, a client may be notified of an attempt to access the directory and/or objects within the directory, which may "stale" the locally cached directory contents (e.g., the cached directory contents may include a list of 5 files within the directory, however, another client may add 3 more files to the directory, which would not be present in the cached directory contents).

In particular, an access request may be received to access an object within the directory (e.g., a second client may be attempting to modify a file object within the directory; a client corresponding to the directory oplock may be attempting to delete a file object within the directory, etc.). It is understood that the access request may include a request to perform an operation on the directory (e.g., rename or delete the directory). The access request may include a second target key and a second parent key. The second target key may specify a unique identifier corresponding to an object within the directory and the client making the access request. The second parent key may specify a unique identifier corresponding to the directory (e.g., the directory is the parent directory of the target object) and the client making the access request.

The second parent key corresponding to the directory may be compared to the first target key corresponding to the directory to determine whether the second parent key and the first target key match. That is, because the respective keys are based on the same client, the second parent key may match the first target key if the client owning the directory oplock is the same client that attempted to access the object within the directory. Otherwise, because the respective keys are based on different clients, the second parent key may not match the first target key if the client attempting to access the object within the directory is different from the client owning the directory oplock.

If the second parent key matches the first target key, the directory oplock is not unlocked because the client owning the directory oplock is the same client that attempted to access the object within the directory. Such a client may be aware that its locally cached directory content is to be updated with its own changes. Conversely, if the second parent key does not match the first target key, the directory oplock is unlocked because the client owning the directory oplock is different from the client attempting to access the object within the directory. When a client accessing an object within the directory makes a change that affects the directory data, the client owning the directory oplock may have cached the directory content that became "old" locally. Thus, a client owning the directory oplock will be notified of the unlock so that the client can take appropriate action to promote data consistency between itself, other clients, and the original directory data.

To the accomplishment of the foregoing and related ends, the following description and annexed drawings set forth certain illustrative aspects and implementations. These are indicative of but a few of the various ways in which one or more aspects may be employed. Other aspects, advantages and novel features of the disclosure will become apparent from the following detailed description when considered in conjunction with the drawings.

Drawings

Fig. 1 is an illustration of an example of the directory contents of a first client's local cache becoming stale when a second client deletes a file within the actual directory.

FIG. 2 is a flow diagram illustrating an example method of managing a directory oplock.

FIG. 3 is a flow chart illustrating an example method of generating a directory oplock.

FIG. 4 is a component block diagram illustrating an example system for managing directory oplocks.

FIG. 5 is an illustration of an example of a directory on which a directory oplock is requested.

FIG. 6 is an illustration of an example of a directory on which a second client, different from the first client owning a directory oplock on the directory, requests access.

FIG. 7 is an illustration of an example of a directory on which a first client owning a directory oplock on the directory requests access.

FIG. 8 is an illustration of an example computer-readable medium that may include processor-executable instructions configured to implement one or more of the provisions set forth herein (provisioning).

FIG. 9 illustrates an example computing environment in which one or more of the provisions set forth herein may be implemented.

Detailed Description

The claimed subject matter is now described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the claimed subject matter. It may be evident, however, that the claimed subject matter may be practiced without these specific details. In other instances, structures and devices are illustrated in block diagram form in order to facilitate describing the claimed subject matter.

Due to the advent of network computing and multitasking, directories and files are often shared among multiple clients (e.g., applications within a computing environment or computers within a network environment). In one example, a file server system may provide network devices with access to shared directories and files. In another example, the local client application may attempt to access the local directory in order to cache the contents of the local directory. However, network bandwidth, resource utilization (e.g., CPU usage, system bus, storage devices, etc.), and/or data coherency issues arise when multiple clients (whether on a network or within a single computing environment) access the same data. Thus, oplocks ("oplocks") may be implemented to allow clients to cache file data locally. That is, the client may request an oplock on the file data, so that the client may assume that the file data will not change as long as the oplock is not attempted to be unlocked by another client attempting to access and/or alter the actual file data. The client can read/write locally cached file data without generating network traffic that accesses actual file data stored, for example, over a network. When completed, the client may update the actual file data with the locally cached file data with a single update. If a second client attempts to access the file data, the oplock may be unlocked and the second client waits while the client owning the oplock is notified of the unlocking. In this manner, the client may update the actual file data with the locally cached file data and provide confirmation of the unlock so that the second client may access the updated file data without awareness of interaction with the first client.

Unfortunately, oplocks are currently available for file data, but not for directory data. The lack of oplocks for directory data may result in unnecessary access requests, such that cached directory data becomes "stale," and/or directories cannot be deleted because a client (e.g., a search indexer, virus scanner, etc.) may not be aware that another client is attempting to delete a directory and/or its contents. In one example, a client that locally caches directory content of a directory may have to implement a refresh mechanism in an attempt to keep the locally cached directory content up to date with respect to potential changes to the actual directory from other clients. Because the actual directory has not been changed, the refresh mechanism may perform unnecessary refreshes. Furthermore, there is a period of time when the locally cached directory content becomes "stale" because another client changed the actual directory and the locally cached directory content has not been refreshed.

Accordingly, one or more systems and/or techniques are provided herein for managing directory oplocks. In particular, a directory oplock for a directory may be created for a first client based on a request for an oplock that includes a first target key and a first parent key. The first client may locally cache directory content of the directory to reduce network traffic. To promote data consistency and mitigate cached directory content from becoming "stale," a notification (e.g., an immediate notification that does not rely on a timer) may be provided to a first client when a second client attempts to access the directory. In this way, the first client may back-flush (flush back) changes to the directory so that the second client may access the latest version of the directory. Further, because the cached content may be "old" if the second client makes changes to the real directory and/or objects within the real directory, the first client may be notified to refresh the locally cached directory content according to the real directory. If the second client is not the same client as the first client, the directory oplock may be unlocked. However, if the second and first clients are the same client, the directory oplock may not be unlocked because the client may be aware of its own changes to the directory.

Fig. 1 illustrates an example 100 of locally cached directory content of a first client becoming "stale" when a second client deletes a file within the actual directory. Server 102 may include a file system configured to provide clients with access to directories and/or files. For example, the server 102 may include an entertainment (folder) directory. The entertainment (folder) directory may include a music (folder) directory, an image (folder) directory, a music playlist (file), a music player (file), an image editor (file), and an image viewer (file). Client (1) 104 (e.g., a file management application) may access the entertainment (folder) directory on server 102 to provide a view of the entertainment (folder) directory to the user. To mitigate network traffic, client (1) 104 may locally store cached directory content corresponding to an entertainment (folder) directory. Client (1) 104 may poll server 102 periodically or as needed to refresh the cached directory content, thereby providing the user with a current view of the file structure. Because the directory content on server 102 may not have changed, refreshing the cached directory content may generate unnecessary network traffic.

Between the time another client makes a change to the entertainment (folder) directory and the time the cached directory content (e.g., an expired view of the entertainment (folder) directory) is refreshed, the cached directory content stored locally on client (1) 104 may become "stale". For example, the client (2) may delete 106 a music playlist (file) on the server 102. However, because there is no directory oplock on the entertainment (folder) directory, client (1) 104 may not be notified of deletions 106 that may affect the "correctness" of cached directory content stored locally on client (1) 104 prior to performing the refresh. That is, if a directory oplock on the entertainment (folder) directory has been provided to client (1) 104, then client (1) 104 may be provided with a notification (e.g., an immediate notification) of the access requested by client (2) corresponding to deletion 106.

One embodiment of managing a directory oplock is illustrated by the example method 200 of FIG. 2. At 202, the method begins. At 204, an oplock request for a directory oplock on a directory is received, for example, from a first client. The oplock request may include a first target key and/or a first parent key. The first target key may specify a unique identifier corresponding to the first client and the directory. The first parent key may specify a unique identifier corresponding to the first client and a parent directory that includes the directory.

At 206, a directory oplock may be generated based on the oplock request. In one example, a read cache directory oplock may be generated such that the first client may locally cache directory content read from the directory. In another example, a read-handle (handle) cache directory oplock may be generated so that the first client may locally cache directory content read from the directory and open a handle on the directory. In another example, a read-write-handle cache directory oplock may be generated such that the first client may locally cache creation, deletion, and/or modification of files in the directory (e.g., attribute modifications such as read-only, file size, etc.). In this manner, a directory oplock may be managed for the first client. In particular, because a second client, different from the first client, is attempting to access/modify the directory and/or objects within the directory, which may change the current state of the directory (e.g., the second client may add file objects to the directory such that the current state of the directory may include a larger overall size and added file objects), or the first client has made changes to the directory that must be flushed back before the second client is aware of the previous change, the first client may be notified of the unlocking of the directory oplock. The notification of the unlock may make the first client aware that the locally cached directory content may be old or that changes made by the first client need to be flushed from its local cache back to the file system.

At 208, an access request to access an object within the directory may be received. For example, a second client (which may be the same or different client as the first client) may request access to perform I/O operations (e.g., modify, add, delete, etc.) on files and/or subdirectories within a directory. It is understood that the access request may include a request to perform an operation on the directory (e.g., rename or delete the directory). The access request may include a second target key and/or a second parent key. The second target key may specify a unique identifier corresponding to the second client and the object within the directory. The second parent key may specify a unique identifier corresponding to the second client and the directory (e.g., the directory is a parent directory of the object because the directory includes the object). It can be appreciated that if the first client and the second client are the same client, the second parent key can have the same identifier as the first target key (e.g., the second parent key specifies the client and the directory, and the first target key specifies the client and the directory).

At 210, if the second parent key does not match the first target key, the directory oplock is unlocked. For example, in the case where a first client owning the directory oplock is different from a second client attempting to access an object within the directory, the second parent key may not match the first target key. The first client may be notified of the directory oplock unlock so that the first client may be informed that the locally cached directory content may have become "stale". If the access request corresponds to a request for a second client to perform an operation on the directory (e.g., delete the directory, set a configuration operation, rename the directory, etc.), a notification is sent to the second client that issued the access request to wait until the unlock is confirmed by the first client.

At 212, if the second parent key matches the first target key, the directory oplock is not unlocked. That is, because the first client owning the directory oplock is the second client that issued the access request, the second parent key matches the first target key. In this manner, the directory oplock is not unlocked when the client owning the directory oplock is the client accessing the object within the directory. The client should be aware of the changes it makes to the directory and therefore should be able to update the locally cached directory contents without notification of the unlocking of the directory oplock.

In one example, the search indexer may issue an oplock request. A directory oplock for the directory may be generated and assigned to the search indexer. A second client (e.g., a file management application) may issue an access request to delete the directory. If the attempted deletion is not notified, the search indexer may continue to access the directory, which may result in failure of the directory deletion. For example, a user may attempt to delete a directory that the search indexer is currently indexing. However, if the deletion is initiated with the search indexer opening the directory, the deletion may fail. Thus, the user may continue to see the directory and/or may not be able to reuse the directory name (e.g., because the directory has not been deleted). Accordingly, if the second parent key does not match the first target key, the directory oplock created by the search indexer may be unlocked. In this manner, the search indexer may be notified to exit the directory so that the user may delete the directory. At 214, the method ends.

One embodiment of generating a directory oplock is illustrated by the example method 300 in FIG. 3. At 302, the method begins. At 304, a directory oplock is generated corresponding to the directory and the client. That is, a directory oplock is an oplock on a directory (e.g., a folder) as opposed to a file. At 306, the method ends.

FIG. 4 illustrates an example of a system 400 configured to manage directory oplocks. The system 400 may include an oplock generator 406 and/or an oplock manager 408. The oplock generator 406 may be configured to receive an oplock request 410 for a directory oplock 412 on a directory. For example, the oplock request 410 may be received from the first client 402. The oplock request 410 may include a first target key and/or a first parent key. The first target key may specify a unique identifier corresponding to the first client 402 and the directory. The first parent key may specify a unique identifier corresponding to the first client 402 and the parent directory that includes the directory.

The oplock generator 406 may generate a directory oplock 412 based on the oplock request 410. In one example, directory oplock 412 may comprise a read-cache oplock. In another example, directory oplock 412 may comprise a read-handle-cache oplock. The oplock generator 406 may send a directory oplock grant notification 414 to the first client 402. In this manner, the second client 402 may locally store directory content within the cached directory content 416. The first client 402 can efficiently perform I/O operations on the cached directory content 416 without generating unnecessary network traffic to access the actual directory.

The oplock manager 408 may be configured to receive an access request 418 to access an object within a directory. For example, the access request 418 may be received from the second client 404 requesting access to a directory, a file within a directory, and/or a sub-directory within a directory. The access request 418 may include a second target key and/or a second parent key. The second target key may specify a unique identifier corresponding to the second client 404 and the object within the directory. The second parent key may specify a unique identifier corresponding to the second client 404 and the directory. It may be appreciated that the first client 402 and the second client 404 may be the same or different clients, which may affect whether the directory oplock 412 is unlocked by the access request 418.

The oplock manager 408 may be configured to perform a match operation 420 to determine whether the first target key matches the second parent key. Because the match indicates that the first client 402 and the second client 404 are the same client, the oplock manager 408 may be configured not to unlock the directory oplock 412 if the second parent key matches the first target key, and thus does not have to notify the client of its own access to the directory.

If the second parent key does not match the first target key, the oplock manager 408 may be configured to unlock the directory oplock 412. The oplock manager 408 may send a directory oplock unlock notification 422 to the first client 402. The directory oplock unlock notification 422 may notify the first client 402 that the cached directory content 416 may be "old". If the access request corresponds to an operation on the directory, the oplock manager 408 may send a notification to the second client 404 to wait until the unlock is confirmed by the first client 402 before accessing the directory.

In one example, the oplock manager 408 may be configured to receive a directory delete access request (e.g., access request 418) that includes an I/O request to perform a directory delete on a directory. The oplock manager 408 may notify the first client 402 associated with the directory oplock 412 to exit the directory so that the second client 404 that issued the directory delete access request may delete the directory.

In one example, the oplock generator 406 may be configured to generate an atomic oplock in response to a directory access request to access a directory. The oplock generator 406 may generate an atomic oplock that spans the period between the directory access request and the oplock request to the directory oplock on the directory. For example, the first client 402 may perform an initial directory access request before performing the oplock request. There is a period of time between the initial directory access request and the generation of the directory oplock, where the first client is "unprotected" because the directory oplock has not yet been generated but the directory has been opened. The atomic oplock may mitigate the sharing violations during this period.

FIG. 5 illustrates an example directory 500 upon which a directory oplock is requested. The file structure 502 may include directories (e.g., folders) and/or files. For example, the file structure 502 may be maintained by a remote file server. In one example, the file structure 502, or a portion thereof, may include an application (folder) 504 directory. The application (folder) 504 directory may be a parent directory of a game (folder) directory, a performance (folder) directory, an entertainment (folder) 506 directory, an installation (file), and/or other objects included within the application (folder) 504 directory. The entertainment (folder) 506 directory may be a parent directory of music (folder) directories, image (folder) directories, music playlists (files), music players (files), image browsers (files), image editors, and/or other objects included within the entertainment (folder) 506 directory.

The remote file server may be configured to allow local and/or remote clients to access directories and files within file structure 502. There are oplocks for directories and/or files. In one example, an oplock request for a directory oplock on an entertainment (folder) 506 directory may be received from a first client. In particular, the first client may be requesting a directory oplock for the entertainment (folder) 506 directory so that the first client can locally cache directory content corresponding to the entertainment (folder) 506 directory. The oplock request may include a first target key and a first parent key. The first target key may specify a unique identifier corresponding to the first client and entertainment (file) 506 directory. The first parent key may specify a unique identifier corresponding to the first client and the application (folder) 504 (e.g., a parent directory of the target entertainment (folder) 506 directory). In this way, a directory oplock may be generated for the first client. The first client may locally cache the directory content. For example, the first client may cache metadata associated with the entertainment (folder) 506 directory and/or a list of files/sub-folders within the entertainment (folder) 506 directory, such as music (folders), images (folders), music playlists (files), music players (files), image browsers (files), image editors (files), and/or other objects.

FIG. 6 illustrates an example 600 of a directory to which a second client, different from the first client owning a directory oplock on the directory, requests access. The file structure 602 may include directories (e.g., folders) and/or files. For example, the file structure 602 or a portion thereof may include an entertainment (folder) 604 directory. The entertainment (folder) 604 directory may be a parent directory of music (folder) directories, image (folder) directories, music playlists (files) 606, music players (files), image browsers (files), image editors (files), and/or other objects included within the entertainment (folder) 604 directory.

It can be appreciated that the first client may own a directory oplock on the entertainment (filer) 604 directory (e.g., fig. 5). In one example, a second client, different from the first client owning the directory oplock, may request access to the music playlist (file) 606. The second client may send an access request including a second target key and a second parent key. The second target keyword may specify a unique identifier corresponding to the second client and the music playlist (file) 606. The second parent key may specify a unique identifier corresponding to the second client and the entertainment (folder) 604 directory (e.g., the parent directory of the target music playlist (file) 606). Because the respective keys are based on different clients (e.g., the first target key is based on the first client and the second parent key is based on a second client different from the first client), the second parent key does not match the first target key and thus the directory oplock may be unlocked. A notification of the directory oplock unlock may be sent to the first client to prevent the first client from maintaining an "old" cache of the entertainment (folder) 604 directory. For example, the second client may modify or delete the music playlist (file) 606, which would not be embodied in the first client's "old" cache.

FIG. 7 illustrates an example 700 of a directory upon which a first client owning a directory oplock on the directory requests access. The file structure 702 may include directories (e.g., folders) and/or files. For example, the file structure 702, or a portion thereof, may include an entertainment (folder) 704 directory. The entertainment (folder) 704 directory may be a parent directory of music (folder) directories, image (folder) directories, music playlists (files) 706, music players (files), image browsers (files), image editors (files), and/or other objects included within the entertainment (folder) 704 directory.

It can be appreciated that the first client may own a directory oplock on the entertainment (folder) 704 directory (e.g., fig. 5). In one example, the second client may request access to a music playlist (file) 706. It is understood that the first client and the second client are the same client in example 700 and are referred to as clients for simplicity. That is, the first client that owns the directory oplock and the second client that requests access to the music playlist (file) 706 are the same client.

It may be advantageous to detect that the same client owning the directory oplock is the same client requesting access, so that the directory oplock is not unlocked due to such access. The client may send an access request including a second target key and a second parent key. The second target key may specify a unique identifier corresponding to the client and the music playlist (file) 706. The second parent key may specify a unique identifier corresponding to the client and entertainment (folder) 704 directory (e.g., the parent directory of the target music playlist (file) 706). Because both the second parent key and the first target key are based on the same client and the same entertainment (folder) 704 directory, the second parent key matches the first target key and the directory oplock may not be unlocked. In this way, the directory oplock is not unlocked because the client need not be provided with a notification that it is accessing the entertainment (folder) 704 directory itself. This notification is unnecessary because the client should be aware of its access to the directory and should be able to take appropriate action with respect to any corresponding cached directory content.

Another embodiment relates to a computer-readable medium comprising processor-executable instructions configured to implement one or more of the techniques presented herein. An example computer-readable medium that may be devised in these ways is illustrated in FIG. 8, wherein the implementation 800 comprises a computer-readable medium 816 (e.g., a CD-R, DVD-R or a platter of a hard disk drive), on which is encoded computer-readable data 814. The computer-readable data 814 in turn comprises a set of computer instructions 812 configured to operate according to one or more of the principles set forth herein. For example, in one such embodiment 800, the processor-executable computer instructions 812 may be configured to perform a method 810, such as the example method 200 of fig. 2 or the example method 300 of fig. 3. In another such embodiment, the processor-executable instructions 812 may be configured to implement a system, such as the example system 400 of fig. 4, for example. Many such computer-readable media may be devised by those of ordinary skill in the art that are configured to operate in accordance with the techniques presented herein.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

As used in this application, the terms "component," "module," "system," "interface," and the like are generally intended to refer to a computer-related entity, either hardware, a combination of hardware and software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, an object, an executable, a thread of execution, a program, and/or a computer. By way of example, both an application running on a controller and the controller can be a component. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers.

Furthermore, the claimed subject matter may be implemented as a method, apparatus, or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof to control a computer to implement the disclosed subject matter. The term "article of manufacture" as used herein is intended to encompass a computer program accessible from any computer-readable device, carrier, or media. Of course, those skilled in the art will recognize many modifications may be made to this configuration without departing from the scope or spirit of the claimed subject matter.

FIG. 9 and the following discussion provide a brief general description of a suitable computing environment to implement embodiments of one or more of the provisions set forth herein. The operating environment of FIG. 9 is only one example of a suitable operating environment and is not intended to suggest any limitation as to the scope of use or functionality of the operating environment. Example computing devices include, but are not limited to, personal computers, server computers, hand-held or laptop devices, mobile devices (such as mobile phones, Personal Digital Assistants (PDAs), media players, and the like), multiprocessor systems, consumer electronics, mini computers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.

Although not required, embodiments are described in the general context of "computer readable instructions" being executed by one or more computing devices. Computer readable instructions may be distributed via computer readable media (discussed below). Computer readable instructions may be implemented as program modules, such as functions, objects, Application Program Interfaces (APIs), data structures, etc., that perform particular tasks or implement particular abstract data types. Typically, the functionality of the computer readable instructions may be combined or distributed as desired in various environments.

FIG. 9 illustrates an example of a system 910 that includes a computing device 912 configured to implement one or more embodiments provided herein. In one configuration, computing device 912 includes at least one processing unit 916 and memory 918. Depending on the particular configuration and type of computing device, memory 918 may be volatile (such as RAM, for example), non-volatile (such as ROM, flash memory, etc., for example) or some combination of the two. This configuration is illustrated in fig. 9 by dashed line 914.

In another embodiment, device 912 may include additional features and/or functionality. For example, device 912 may also include additional storage (e.g., removable and/or non-removable) including, but not limited to, magnetic storage, optical storage, and the like. Such additional storage is illustrated in FIG. 9 by storage 920. In one embodiment, computer readable instructions to implement one or more embodiments provided herein may be in storage 920. Storage 920 may also store other computer readable instructions to implement an operating system, an application program, and the like. Computer readable instructions may be loaded in memory 918 for execution by processing unit 916, for example.

The term "computer readable media" as used herein includes computer storage media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions or other data. Memory 918 and storage 920 are examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVD) and other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by device 912. Any such computer storage media may be part of device 912.

Device 912 may also include communication connection(s) 926 that allow device 912 to communicate with other devices. Communication connection(s) 926 may include, but is not limited to, a modem, a Network Interface Card (NIC), an integrated network interface, a radio frequency transmitter/receiver, an infrared port, a USB connection, or other interfaces for connecting computing device 912 to other computing devices. Communication connection(s) 926 may include a wired connection or a wireless connection. Communication connection(s) 926 may transmit and/or receive communication media.

The term "computer readable media" may include communication media. Communication media typically embodies computer readable instructions or other data in a "modulated data signal" such as a carrier wave or other transport mechanism and includes any information delivery media. The term "modulated data signal" may include a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal.

Device 912 may include input device(s) 924 such as keyboard, mouse, pen, voice input device, touch input device, infrared cameras, video input devices, and/or any other input device. Device 912 may also include output device(s) 922 such as one or more displays, speakers, printers, and/or any other output device. Input device(s) 924 and output device(s) 922 may be connected with device 912 via a wired connection, wireless connection, or any combination thereof. In one embodiment, an input device or an output device from another computing device may be used as input device(s) 924 or output device(s) 922 for computing device 912.

Components within computing device 912 may be connected by various interconnects, such as a bus. These interconnects may include Peripheral Component Interconnects (PCI), such as PCI express, Universal Serial Bus (USB), firewire (IEEE 1394), optical bus structures, and the like. In another embodiment, components of computing device 912 may be interconnected by a network. For example, memory 918 may be comprised of multiple physical memory units located in different physical locations interconnected by a network.

Those skilled in the art will appreciate that storage devices utilized to store computer readable instructions can be distributed over a network. For example, a computing device 930 accessible via network 928 may store computer readable instructions to implement one or more embodiments provided herein. Computing device 912 may access computing device 930 and download a part or all of the computer readable instructions for execution. Alternatively, computing device 912 may download pieces of the computer readable instructions, as needed, or some instructions may be executed at computing device 912 and some at computing device 930.

Various operations of embodiments are provided herein. In one embodiment, one or more of the operations may constitute computer readable instructions stored on one or more computer readable media, which if executed by a computing device, will cause the computing device to perform the operations. The order in which some or all of the operations are described should not be construed as to imply that these operations are necessarily order dependent. Those skilled in the art will recognize other sequences after having the benefit of this description. In addition, it will be understood that not all operations are necessarily present in each embodiment provided herein.

Moreover, the word "exemplary" is used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects or designs. Rather, use of the word example is intended to present concepts in an abstract form. As used in this application, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or". That is, unless specified otherwise, or clear from context, "X employs A or B" is intended to mean any of the natural inclusive enumerations. That is, if X employs A; x is B; or X employs both A and B, then "X employs A or B" is satisfied under any of the foregoing instances. In addition, the indefinite articles "a" and "an" as used in this application and the appended claims may generally be construed to mean "one or more" unless specified otherwise or clear from context to be directed to a singular form.

Also, although the disclosure has been shown and described with respect to one or more implementations, equivalent alterations and modifications will occur to others skilled in the art based upon a reading and understanding of this specification and the annexed drawings. The present disclosure includes all such modifications and alterations, and is limited only by the scope of the following claims. In particular regard to the various functions performed by the above described components (e.g., elements, resources, etc.), the terms used to describe such components are intended to correspond, unless otherwise indicated, to any component which performs the specified function of the described component (e.g., that is functionally equivalent), even though not structurally equivalent to the disclosed structure which performs the function in the herein illustrated exemplary implementations of the disclosure. In addition, while a particular feature of the disclosure may have been disclosed with respect to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given or particular application. Furthermore, to the extent that the terms "includes," has, "" with, "or variants thereof are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term" comprising.

Claims (13)

1. A method (200) for managing directory oplocks, comprising:

receiving (204), from a first client, an oplock request for a directory oplock on a directory, the oplock request comprising a first target key and a first parent key, the first target key specifying unique identifiers corresponding to the first client and the directory, and the first parent key specifying unique identifiers corresponding to the first client and a parent directory comprising the directory;

generating (206) the directory oplock based on the oplock request;

receiving (208), from a second client, an access request to access an object within the directory, the access request including a second target key and a second parent key, the second target key specifying a unique identifier corresponding to the second client and the object within the directory, and the second parent key specifying a unique identifier corresponding to the second client and the directory;

unlocking (210) the directory oplock if the second parent key does not match the first target key; and

not unlocking (212) the directory oplock if the second parent key matches the first target key.

2. The method of claim 1, comprising:

and when the directory oplock is unlocked, sending a notification of unlocking to the first client sending the oplock request.

3. The method of claim 2, comprising:

sending a notification to a second client that issued the access request corresponding to the second client's request to perform an operation on the directory to wait until the unlocking is confirmed by the first client.

4. The method of claim 1, comprising:

upon determining that the second parent key matches the first target key, determining that a first client issued the oplock request, that the first client owns the directory oplock, and that the first client issued the access request.

5. The method of claim 1, the generating the directory oplock comprising at least one of:

generating a read-write-handle-cache oplock;

generating a read-cache oplock; and

a read-handle-cache oplock is generated.

6. The method of claim 1, the access request to access an object within the directory comprising an I/O request to perform at least one of:

modifying file objects within the directory;

modifying the subdirectory objects in the directory;

adding a file object to the directory;

adding a subdirectory object in the directory;

deleting the file objects in the directory; and

and deleting the subdirectory objects in the directory.

7. The method of claim 1, comprising:

assigning the directory oplock to the first client that issued the oplock request; and

if the second parent key does not match the first target key, notifying the first client to exit the directory so as to allow the second client which sends the access request to execute the operation on the directory.

8. A system (400) for maintaining a directory oplock, comprising:

an oplock generator (406) configured to:

receiving, from a first client, an oplock request for a directory oplock on a directory, the oplock request including a first target key and a first parent key, the first target key specifying unique identifiers corresponding to the first client and the directory, and the first parent key specifying unique identifiers corresponding to the first client and a parent directory that includes the directory; and

generating the directory oplock based on the oplock request; and

an oplock manager (408) configured to:

receiving, from a second client, an access request to access an object within the directory, the access request including a second target key and a second parent key, the second target key specifying a unique identifier corresponding to the second client and the object within the directory, and the second parent key specifying a unique identifier corresponding to the second client and the directory;

unlocking the directory oplock if the second parent key does not match the first target key; and

if the second parent key matches the first target key, the directory oplock is not unlocked.

9. The system of claim 8, the oplock generator configured to:

an atomic oplock is generated in response to a directory access request to access the directory.

10. The system of claim 9, the atomic oplock spans a period between the directory access request and the oplock request for a directory oplock on the directory.

11. The system of claim 8, the oplock manager configured to:

sending a notification of a directory oplock unlock to the first client that issued the oplock request.

12. The system of claim 11, the oplock manager configured to:

sending a notification to a second client that issued the access request corresponding to the second client's request to perform an operation on the directory to wait until the unlocking is confirmed by the first client.

13. The system of claim 8, the oplock manager configured to:

receiving a directory access request comprising an I/O request to perform an operation on the directory; and

notifying a client associated with the directory oplock to exit the directory for the client issuing the directory access request to perform the operation on the directory.