CN1276568A - Multi-protocol unified file lockout - Google Patents

Abstract

The present invention provides a method and system for correct interoperability of multiple different file servers or file locking protocols using a proposed multi-protocol lock management system. The file server determines whether there are inconsistencies with existing locks regardless of the originating client device and originating file server protocol or file locking protocol for those existing locks before allowing any client device to access data or acquire a lock. CIFS client devices can acquire a "change watch" lock on a directory in the file system. The file server records the change of the directory by the CIFS client device and the non-CIFS client device, and notifies the CIFS client device of the "change monitoring" lock of the change.

Description

Multi-protocol unified file locking

The present invention relates to locking in multi-protocol file servers.

In an integrated computer network, multiple client devices need to share files. One known approach is to provide a network file server for storing files that is capable of receiving and responding to file server requests from those client devices. These file server requests are generated using a file server protocol recognized and adhered to by the file server and the client device. Since the files are stored in the file server, multiple client devices have the opportunity to access the files at the same time.

One problem in the prior art is that there are many different file server protocols, each of which has different semantic relationships for file operations. It is known to provide a file server capable of recognizing multiple file server protocols, but this is very difficult as many file server protocols have different and incompatible semantic relationships with respect to file locking and file sharing. Incompatible locking semantics present difficulties in serving a single file system to multiple different client devices. If the first client device complies with the first file server protocol (with the first file locking semantic relationship), a second client device using the second file server protocol (with different file locking semantic relationship) will cause the first client device's Application failed critically. The correct operation of each file server protocol depends on the compatibility of all other file server protocols with their file locking semantics.

For example, one protocol commonly used on devices utilizing the Unix operating system (or variants thereof) is the NFS ("Network File System") protocol. By implementing "PC NFS", devices utilizing the Windows operating system (or variants thereof) also utilize the NFS protocol. The NFS protocol is designed to be stateless, so as not to provide any semantic relationship for files that are locked or otherwise restricted to a client device relative to a share. Conversely, a protocol commonly used for devices utilizing the Windows operating system is the CIFS ("Common Internet File System") protocol. The CIFS protocol has a broadly mandatory file locking semantic relationship, which is complied with and insisted on by CIFS client devices.

In known systems, the NFS protocol has been augmented with an additional file locking protocol NLM ("Network Lock Manager"), but the NFS protocol only considers NLM locking as advisory. While this approach achieves the goal of providing file-locking semantics to NFS applications that utilize it, it does not prevent NFS applications from ignoring those file-locking semantics, nor does it allow client devices to conform to multiple different file server protocols. File locking semantic relationship.

Accordingly, it would be desirable to provide a method and system for enforcing file locking semantics in client devices utilizing a variety of different file server protocols. An embodiment of the present invention enables this effect where a unified set of file locking semantics is loaded into the kernel of a multi-protocol file server and enforced on client devices utilizing any of the different file server protocols recognized by the server implement. In the preferred embodiment, to protect data integrity during client access to a shared file system residing on a network file server, CIFS protocol specific file locking semantics are implemented to allow NFS client devices to interact with CIFS client devices interoperable.

The invention provides a correct interoperability method and system of multiple different file server protocols. A file server that recognizes multiple different file server protocols provides a unified multi-protocol lock management system (including a unified semantic relationship between file locks) that enforces the implementation of all client devices and all recognized file server protocols. In the preferred embodiment, a first file server protocol (such as CIFS) enforces file open and file locking semantics and an opportunistic file locking technique, while a second file server protocol (such as NFS and additional protocol NLM) lacks file-open semantics and provides file-lock semantics only for advisory byte-ranges.

The unified file lock semantic relationship enables a file server to determine whether to agree with the originating client device and the originating file server for those existing locks before allowing any client device to read or write data or acquire a new file lock or byte range lock. or an existing locking inconsistency independent of the file locking protocol. In the case of a CIFS client device attempting to read or write data, the file server performs this check when the client device opens the file. In the case of a CIFS client device requesting a byte-range lock, the file server performs this check when the client device requests a byte-range lock. For NFS clients, the file server performs this check when the client device actually sends a read or write request, or when the NFS client device requests an NLM byte-range lock indicating the byte range to read or write. Enforces file locking semantics to protect file data from corruption caused by NFS client devices.

In a second aspect of the present invention, a CIFS client device, while opening a file, can acquire an "oplock" (opportunistic lock), an exclusive file lock that only allows one client to read or write the file. When a client device sends a non-CIFS (that is, NFS or NLM) protocol request for an opportunistically locked file, the file server sends an opportunistic lock break message to the CIFS client device, and at the same time flushes any cached write operations and Chances of possibly closing the file. Allowing NFS and NLM requests to interrupt opportunistic locking ensures that file data remains available to NFS client devices while protecting file data integrity.

In a third aspect of the present invention, a CIFS client device can acquire a "change detection" lock on a directory in the file system so that the file server notifies when changes are made to the directory (changes to a directory are included in the directory create, delete, or rename files within, or move files into or out of that directory). The file server records changes to the directory by both CIFS client devices and non-CIFS client devices, and notifies those CIFS client devices of the "change watch" locks for those changes.

Figure 1 shows a first block diagram of a system comprising a multi-protocol file server.

Figure 2 shows a second block diagram of a system including a multi-protocol file server.

Figure 3 shows a flowchart of a method of operating a multi-protocol file server.

Figure 4 shows a flowchart of a method of operating a cross-protocol lock manager in a multi-protocol file server.

Figure 5 shows a flowchart of a method of operating an opportunistic lock manager in a multi-protocol file server.

Figure 6 shows a flowchart of a method of operating a change notification manager in a multi-protocol file server.

In the following description, preferred embodiments of the invention are described with reference to preferred process steps and data structures. Those skilled in the art, after studying this application, will recognize that embodiments of the invention can be implemented using a general-purpose or special-purpose processor or other circuitry adapted to the specific process steps and data structures described herein, and implementing the The described process steps and data structures do not require special experimentation or further invention.

System structure (client/server)

Figure 1 shows a first block diagram of a system comprising a multi-protocol file server.

A system 100 includes a file server 110 , a computer network 120 and a plurality of client devices 130 .

The file server 110 includes a processor 111 and mass storage 112 . Mass storage 112 is capable of storing and retrieving a set of files 113 with data for storage and retrieval. Processor 111 is capable of receiving a series of request messages 121 from network 120, parsing those messages as commands and data, processing files 113 on mass storage 112 and sending response messages based on those commands and data.

File server 110 and client device 130 are connected to network 120 and communicate using messages 121 transmitted over network 120 . The message 121 includes a file system request sent by the client device 130 to the file server 110 and a file system response sent by the file server 110 to the client device 130 .

System structure (file locking semantic relationship)

Figure 2 shows a second block diagram of a system including a multi-protocol file server.

System 100 includes a set of client devices 130, including Unix client device 201, PC NFS Windows client device 202, and CIFS Windows client device 203. The Unix client device 201 executes the Unix operating system and utilizes the Unix/NFS file server protocol. The PC NFS Windows client device 202 executes the Windows operating system and utilizes the PC NFS file server protocol. The CIFS Windows client device 203 executes the Windows operating system and utilizes the CIFS file server protocol.

Unix client device 201 and PC NFS Windows client device 202 utilize the NFS file server protocol to communicate with the file server 110, and the protocol is confirmed by an NFS file server protocol analysis program 211 in the file server 110. The CIFS Windows client device 203 utilizes the CIFS file server protocol to communicate with the file server 110, and the protocol is confirmed by a CIFS file server protocol analysis program 212 in the file server 110. Messages using the NFS file server protocol or the CIFS file server protocol are parsed by processor 111 and processed by an opportunistic lock manager 220 .

Opportunistic lock manager 220 accesses files 113 with CIFS opportunistic locks. The operation thereof will be described in detail later with reference to FIGS. 3 and 5 . The opportunistic lock manager component 220 interfaces with a cross-protocol lock manager 230 .

The cross-protocol lock manager 230 manages the file locking semantics of the file server 110 . It processes and records information related to four types of locks - CIFS byte range locks 241 , CIFS file locks 242 , PC NFS (NLM) file locks 243 and NLM byte range locks 244 . The operation thereof will be described in detail later with reference to FIGS. 3 and 4 .

Different file locking semantics

As shown in Figure 2, can receive file server request message 140 from Unix client device 201, PC NFS Windows client device 202 or CIFSWindows client device 203, and can use NFS file server protocol or CIFS file server protocol. In addition to using different file server protocols, each type of client device 130 also has a different file locking model provided by file server 110 .

In particular, the NFS file server protocol is used to perform file system operations that do not have any form of file open or file close semantic relationship. These NFS file system operations include read or write operations on file data or file system transactions (ie, read and write operations on directories). File system processing includes creating files or directories, renaming files or directories, moving files from one directory to another, or undoing (deleting) files or directories from the file system.

The NLM add-on protocol is used to acquire and release byte-range locks on files. These byte range locks may be "read locks," which inhibit other compliant applications (eg, in other client devices 130) from writing to a particular byte range. These byte range locks can also be "write locked", which inhibits other follower applications from reading or writing to or from a specific byte range.

The CIFS file server protocol is used to perform file open operations and acquire file locks on the files 113 to be opened before attempting any read or write operations on the data in those files 113 . When opening a file, a CIFS client device 130 can specify the desired access mode (read-only, write-only, or read-write) and the desired deny mode ( No Deny, Read Deny, Write Deny, or All Deny). CIFS file system operations then only need to check the access mode of the obtained file open. A CIFS client device 130 can also specify byte range locks on byte ranges in a file opened by the client device 130 . A byte range lock is either an exclusive lock also known as a "write lock" (with read-write access mode and deny-all deny mode), or a non-exclusive lock also known as a "read lock" (with only read access mode and write deny deny mode).

The file server 110 determines a lock mode that combines the access mode and the deny mode. As used herein, the phrase "lock mode" refers to a unified lock mode generated by file server 110 that combines an access mode and a deny mode.

When opening a file, a CIFS client device 130 can also obtain an oplock (opportunistic lock), which allows the CIFS client device 130 that opened the file to have exclusive access to the file, as long as another client device 130 does not attempt to use the file. From the needs of the client device 130, the oplock provides a higher degree of exclusiveness to the file, and access by another client device 130 can interrupt the exclusiveness of the oplock.

File server 110 is prepared for proper interworking between client devices 130 using NFS (with or without additional protocol NLM) or CIFS. In order to provide proper interoperability, the file server 110 provides a unified file locking semantic relationship. In the preferred embodiment, the unified file locking semantics have the following effects:

File server 110 prevents Unix client device 201 from performing NFS write operations that would overwrite data in file 113 that has been opened and is being used by a CIFS client with a deny mode of write deny or deny all.

File server 110 prevents Unix client device 201 and PC NFS Windows client device 02 from performing NFS file system operations that would result in canceling or renaming a file 113 that has been opened and is being used by a CIFS client.

When a Unix client device 201 or a PC NFS Windows client device 202 generates an NFS request to cancel, rename or write data to a file 113 that is locked by a CIFS client, the file server 110 will implement CIFS opportunistic locking semantics on the file 113 . The file server 110 sends an op-lock abort message 140 to the client device 130 holding the op-lock, and receives a response message from the client device 130 . If the client device 130 closes the file 113, the NFS request can continue and be allowed by the file server 110.

When a Unix client device 201 or a PC NFS Windows client device 202 generates an NFS request to read data from a file 113 that is locked by a CIFS client, the file server 110 will enforce CIFS opportunistic lock semantics on the file 113. The file server 110 sends an op-lock abort message 140 to the client device 130 holding the op-lock, and receives a response message from the client device 130 . If the client device 130 closes the file 113 or flushes its write buffer to the file server 110, the NFS request can continue and be allowed by the file server 110.

The file server 110 tests the mutual compatibility of the file open request from the CIFS Windows client device 203 and the NLM file lock request from the PCNFS Windows client device 202 with respect to their specific locking modes. The well-known phrase NLM "shared locking" is here replaced by the phrase NLM "file locking", which is described in the following document: "X/Open CAE Specification: Protocols for X/OpenInterworking XNFS, Issue 4 (X/Open Document Number C218) ", which is here used as a reference. File server 110 determines a specific lock mode by combining the requested access mode and deny mode.

To provide these effects, file server 110 performs the following lock management operations:

While receiving a CIFS file open request message 140, the file server 110 tests for file open requests that conflict with existing CIFS and NLM file locks as well as with existing NLM byte range locks. For comparison purposes with newly requested file locks, file server 110 treats existing NLM byte range locks as non-exclusive locks with non-deny deny mode and with read-only access mode and exclusive with read-write access mode. locking.

While receiving a CIFS byte range lock request message 140, file server 110 tests for byte range lock requests that conflict with existing CIFS and NLM byte range locks.

While receiving an NLM byte-range lock request message 140, file server 110 tests for byte-range lock requests that conflict with existing CIFS and NLM byte-range locks and that conflict with existing CIFS file locks.

While receiving an NLM file lock request message 140 (for simulating a file open request message 140) from a PC NFS client device 130, the file server 110 tests for conflicts with existing CIFS and NLM file locks and with existing NLM NLM file lock request with byte range lock conflict. For purposes of comparison with newly requested NLM file locks, file server 110 treats existing NLM byte range locks as having a non-deny deny mode with a non-exclusive lock with a read-only access mode and a read-write access mode. Exclusive lock.

How to operate (multi-protocol file server)

Figure 3 shows a flowchart of a method of operating a multi-protocol file server.

The method 300 of operating a multi-protocol file server includes a set of process steps and flow points performed by the file server 110 in cooperation with at least one client device 130 .

At flow point 310 , file server 110 is ready to receive file server request message 140 .

At step 311 , the file server 110 receives and analyzes the file server request message 140 . The file server 110 determines whether the file server request message 140 utilizes the NFS file server protocol, the NLM file locking protocol, or the CIFS file server protocol. If the file server request message 140 uses the NFS file server protocol or the NLM file locking protocol, the method 300 continues to step 312 . If the file server request message 140 uses the CIFS file server protocol, the method 300 continues to step 313 .

In step 312, the file server 110 determines whether the request message 140 includes an NFS file server request to perform a file system operation (eg, read or write data, or modify a directory). Alternatively, file server 110 determines whether request message 140 includes an NLM file lock request to obtain an NLM byte range lock. In either case, method 300 continues to flow point 320 .

In step 313, the file server 110 determines whether the file server request message 140 is to perform a CIFS read or write operation to obtain a CIFS byte range lock, or to perform a CIFS file open operation. In the event that the file server request message 140 is to acquire a CIFS byte range lock or to perform a CIFS file open operation, the method 300 proceeds to flow point 320 . If the file server request message 140 is to perform a CIFS read or write operation, the method continues to flow point 330 . If the file server request message 140 is changed to be a CIFS "Change Notification" request, the method continues to flow point 350 (change notification requests will be further described with reference to FIG. 6).

At flow point 320 , file server 110 is ready to compare the operation requested by file server request message 140 with the file lock status of file 113 . The file lock status of file 113 includes existing file locks and byte range locks for file 113 .

In step 321, the file server 110 determines that the file 113 is the subject of the file server request message 140 and determines whether the file 113 is opportunistically locked. If file 113 is opportunistically locked, method 300 continues to step 322 . If file 113 is not opportunistically locked, method 300 continues to step 323 .

At step 322, file server 110 breaks the opportunistic lock, as described herein. The execution of step 322 will be further described later with reference to FIG. 5 . Breaking an opportunistic lock can cause the file lock status of file 113 to change.

In step 323, file server 110 compares the requested operation to the file lock status of file 113 using a unified file lock semantic relationship. In this step, the requested operation may be an NFS read or write operation, an NFS or CIFS directory modification operation, an attempt to acquire an NLM file lock or byte range lock, or a CIFS file open operation. The execution of step 323 and the unified file locking semantic relationship will be further described later with reference to FIG. 4 . If the comparison shows that the requested operation is allowed, method 300 continues to step 324 . If the requested operation is not permitted, method 300 continues to step 325 .

In step 324, the file server 110 performs the requested operation. Method 300 continues to flow point 340 .

At step 325, the file server 110 refuses to perform the requested operation and responds to the client device 130 with an error message. Method 300 continues to flow point 340 .

At flow point 330 , file server 110 is ready to compare the operation requested by file server request message 140 with the file lock status of file 113 .

At flow point 350, file server 110 is ready to perform change notification operations, as described herein.

In step 351, the first CIFS client device 130 requests a file lock for a directory (using a file system request message 140 to open the directory), and converts the file lock of the directory into a change monitoring lock of the directory. The execution of this step 351 will be further described later with reference to FIG. 6 .

At flow point 340, the file server 110 has responded to the file server request message 140, with respect to which the method 300 is complete.

How-To (Cross-Protocol Lock Manager)

Figure 4 shows a flowchart of a method of operating a cross-protocol lock manager in a multi-protocol file server.

The method 400 of operating a cross-protocol lock manager in a multi-protocol file server includes a set of process steps and flow points performed by the file server 110 in cooperation with at least one client device 130 as described below.

At flow point 410 , file server 110 is ready to compare the operation requested in file server request message 140 with the file lock status of file 113 .

File server 110 utilizes a unified file locking semantics to model file locking from any request operation of any file server protocol in the same manner. The unified file lock semantic relationship identifies a unified set of file locks, each file lock including an access mode for requesting client devices 130 and a deny mode for all other client devices 130 .

In the preferred embodiment, the access mode can be one of the following three possibilities - read only, write only or read-write. Likewise, in the preferred embodiment, the deny mode can be one of four possibilities - no deny, read deny, write deny or all deny.

After the first client device 130 obtains a file lock to a file 113, if the lock mode determined by the file server 110 to be requested by the second client device 130 is consistent with the file lock status of the file 113, the second client device 130 can only access the file 113 . For example, a first client device 130 acquires a file lock on a file 113 with a deny mode of write deny. The second NFS client device 130 can attempt to write to the file 113 or the second CIFS client device 130 can attempt to open the file 113 with an access mode that includes write access. In either case (if the file lock on the file 113 is not an opportunistic lock, as described below), the file server 110 will deny the second client device 130's request.

As mentioned, the file server 110 performs the comparison of file locks and access requested by the second client device 130 at different times according to the file server protocol used by the second client device 130:

If the second client device 130 uses the CIFS file server protocol to open the file 113, the file server 110 checks the file lock status of the file 113 when opening the file.

If the second client device 130 uses the NFS file server protocol to read or write the file 113, the file server 110 checks the file lock status of the file 113 when performing actual file system operations. This also applies to file system operations that have the effect of erasing the file from the first client device 130, such as operations to move, delete or rename the file 113.

If the second client device 130 requests a byte range lock using the CIFS file server protocol, the file server 110 checks the file lock status of the file 113 that conflicts with other CIFS or NLM byte range locks at the time the byte range lock is requested. File server 110 does not check for conflicts with other CIFS file locks when requesting a byte-range lock, because the check is done when the file is opened.

If the second client device 130 uses the NLM protocol to request a byte-range lock, the file server 110 checks for conflicts with existing CIFS or NLM byte-range locks and with existing CIFS file locks when requesting a byte-range lock. The file lock status of the file 113 with lock conflicts.

In step 421, file server 110 determines whether more than one file lock already exists associated with file 113. If yes, method 400 continues to step 422 . If not, the method continues to step 411.

In step 422 , file server 110 combines the file locks already associated with file 113 into an equivalent file lock associated with file 113 . To perform this step 422, the file server 110 crosses Table 1 for an accumulated file lock that includes each type of pre-existing file lock until all pre-existing file locks have been accumulated together.

Table 1 shows a lock conversion table in a multi-protocol file server with unified file lock semantic relationship. Existing file lock mode NewLockMode NULL A:RD:DR A:WD:DR A:RWD:DN A:RD:DR A:WD:DR A:RWD:DR A:RD:DW A:WD:DW A:RWD:DW A: Any D: DA NULL NULL A:R A:W A:RW A:R A:W A:RW A:R A:W A:RW A:AnyD.DN D.DN D.DN D.DR D.DR D.DR D:DW D:DW D: DW D.DAA:R A:R A:RW A:RW A:R A:RW A:RW A:R A:RW A:RW A:AnyD:DN D:DN D:DN D:DN D:DR D:DR D :DR D:DW D:DW D:DW D:DAA:W A:RW A:W A:RW A:RW A:W A:RW A:RW A:W A:RW A:AnyD:DN D:DN D:DN D: DN D: DR D: DR D: DR D: DW D: DW D: DW D: DAA: RW A: RW A: RW A: RW A: RW A: RW A: RW A: RW A: RW A: RW A: AnyD: DN D: DN D: DN D: DN D: DR D: DR D: DR D: DW D: DW D: DW D: DAA: R A: R A: RW A: RW A: R A :RW A:RW A:Any A:Any A:Any A:AnyD:DR D:DR D:DR D:DR D:DR D:DR D:DR D:DR D:DA D:DA D:DA D:DAA: W A: RW A: W A: RW A: RW A: W A: RW A: Any A: Any A: Any A: Any D: DR D: DR D: DR D: DR D: DR D: DR D: DR D: DA D:DA D:DA D:DAA:RW A:RW A:RW A:RW A:RW A:RW A:RW A:Any A:Any A:Any A:AnyD:DR D:DR D:DR D: DR D: DR D: DR D: DR D: DA D: DA D: DA D: DAA: R A: R A: RW A: RW A: Any A: Any A: Any A: R A: RW A: RW A:Any D:DW D:DW D:DW D:DA D:DA D:DA D:DA D:DW D:DW D:DW D:DAA:W A:RW A:W A:RW A:Any A:Any A:Any A:RW A:W A:RW A:AnyD:DW D:DW D:DW D:DW D:DA D:DA D:DA D:DW D:DW D:DW D:DAA:RW A: RW A: RW A: RW A: Any A: Any A: Any A: RW A: RW A: RW A: Any D: DW D: DW D: DW D: DA D: DA D: DA D: DA D: DW D: DW D: DW D: DAA: Any A: Any A: Any A: Any A: Any A: Any A: Any A: Any A: Any A: Any A: Any D: DA D: DA D: DA D:DA D:DA D:DA D:DA D:DA D:DA D:DA D:DA A:RD:DN A:WD:DN A:RWD:DN A:RD:DR A:WD:DR A:RWD:DR A:RD:DW A:WD:DW A:RWD:DW A: Any D: DA

Table 1

lock transformation matrix

A - Access Mode (R=Read, W=Write, RW=Read-Write, Any=R or W or RW)

D-Deny Mode (DN=Non-Deny, DR=Read Deny, DW=Write Deny, DA=Deny All)

At step 411 , the file server 110 determines the nature of the operation requested in the file server request message 140 . If the requested operation is a CIFS file open operation, method 400 continues to step 423 . If the requested operation is an NFS file server operation, method 400 proceeds to step 431. If the requested operation is a CIFS request or NLM request for a byte range lock, then the file system 110 proceeds to step 441 .

At step 423 , the file server 110 compares the file lock already associated with the file 113 with the file open requested by the second client device 130 . In order to perform this step 423, the file server 110 cross-checks the pre-existing file lock and the requested new access mode and deny mode in Table 2, and allows or denies the requested new access mode and deny mode according to the relevant entries in the table .

If the file server 110 allows the requested new access mode and deny mode, the method 400 proceeds to step 424 . Method 400 does not perform step 424 if file server 110 denies the requested new access mode and denial mode.

Table 2 shows a cross-reference of attempted file locks in a multi-protocol file server with unified file lock semantics. Pre-existing file lock NewModeBeingRequ-ested NULL A:RD:DN A:RD:DR A:RD:DW A:WD:DN A:WD:DR A:WD:DW A:RWD:DN A:RWD:DR A:RWD:DW A: Any D: DA NULL √ √ √ √ √ √ √ √ √ √ √ A:RD:DN √ √ x √ √ x √ √ x √ x A:RD:DR √ x x x √ x √ √ x √ x A:RD:DW √ √ x √ x x x x x x x A:WD:DN √ √ √ x √ √ x √ √ x x A:WD:DR √ x x x √ √ x x x x x A:WD:DW √ √ √ x x x x x x x x A:RWD:DN √ √ x x √ x x √ x x x A:RWD:DR √ x x x √ x x x x x x A:RWD:DW √ √ x x x x x x x x x A: Any D: DA √ x x x x x x x x x x

Table 2

Multi-Protocol Lock Compatibility Matrix

A = access mode D = deny mode

√ - new requests will be authorized × - new requests will be denied

As shown in Table 2, each pair of pre-existing file locks and the requested new access mode and denial mode has a related decision relationship to allow or deny the requested new access mode and denial mode.

If the file server 110 is checking for a conflict between an existing CIFS file lock and a new request to perform a file open operation, the existing CIFS file lock is cross-retrieved for the access mode and deny mode requested in the new file open request .

If the file server 110 is checking for conflicts between existing file locks and a new NFS request to perform a file read or write operation, then interleave the requested access patterns for the total lock pattern (combination of existing file locks) ) to perform a new request.

If the file server 110 is checking for conflicts between existing file locks or byte-range locks and a new request for an NLM byte-range lock, interleave a lock mode equivalent to a new NLM byte-range lock request Retrieves existing file locks and byte range locks. For comparison with existing file locks, file server 110 treats newly requested NLM byte range locks as non-deny deny mode, and as non-exclusive locks with read-only access mode (also called "read locks") and exclusive locks (also known as "write locks") with a read-write access mode. For comparison with existing byte-range locks, file server 110 treats a newly requested NLM byte-range lock as a read lock with read-only access mode and write-deny deny mode, and as a read lock with read-write access mode and all Deny a write lock in deny mode.

Method 400 then continues to flow point 450 .

In step 431 , the file server 110 compares the file lock status of the file 113 with the operation requested by the second client device 130 . To execute this step 431, the file service server 110 compares the denial mode of the file lock with the requested operation, and allows or rejects the requested operation according to the comparison result.

Method 400 then continues to flow point 450 .

At step 441 , the file server 110 compares the file lock status of the file 113 with the NLM byte range lock requested by the second client device 130 . In the preferred embodiment, CIFS byte-range lock requests are only checked for byte-range locks, since they require a previous CIFS file open operation that has already checked for an existing file lock. To perform this step 441, the file server 110 cross-checks the pre-existing file lock status and the requested byte range lock in Table 3, and allows or denies the requested byte range lock according to the relevant entry in the table.

If the file server 110 allows the requested new NLM byte range lock, the method 400 proceeds to step 442 . If the file server 110 denies the requested new byte range lock, then method 400 does not perform step 442.

Table 3 shows the cross-references of existing file locks and newly requested NLM byte range locks in a multi-protocol file server with unified file lock semantic relations. Existing lock mode none A:RD:DN A:RD:DR A:RD:DW A:WD:DN A:WD:DR A:WD:DW A:RWD:DN A:RWD:DR A:RWD:DW A: Any D: DA WriteLock √ √ √ x √ √ x √ √ x x ReadLock √ √ x √ √ x √ √ x √ x

table 3

Compatibility of new NLM byte range locks with existing file locks

A = access mode, D = deny mode

√ = new NLM byte range lock requests will be granted

× = new NLM byte range lock requests will be denied

As shown in Table 3, each pair of an existing file lock and a newly requested NLM byte range lock has an associated decision relationship of allowing or denying the requested new byte range lock.

In step 442, file server 110 associates the requested new byte range lock with file 113 as a new additional byte range lock.

Method 400 continues to flow point 450 .

At flow point 450, file server 110 compares the operation requested in file server request message 140 with the file lock status of file 113 and allows or denies the requested operation.

How-To (Opportunistic Lock Manager)

Fig. 5 shows a flowchart of a method of operating an opportunistic lock manager in a multi-protocol file server.

The method 500 of operating an opportunistic lock manager in a multi-protocol file server includes a set of process steps and flow points performed by the file server 110 in cooperation with at least one client device 130 as described below.

In the field of file locking under the Windows operating system environment, opportunistic locking is a known technology. The technology is described in detail in the literature on the "Windows NT 4.0" operating system including, for example, the IETF specification for CIFS, available via the file cifs6.doc or cifs6. txt, obtained from Microsoft Corporation, Washington, Redmond, and used as a reference herein.

At flow point 510, the file server 110 is ready to receive a request to open a file 113 from a CIFS first client device 130.

In step 511, the file server 110 receives a file open request for the file 113 from a CIFS first client device 130. The file open request specifies an access mode and a deny mode.

In step 512, the file server 110 determines that the request should be allowed and grants a file lock to the first client device 130 in the specified access mode and deny mode.

In step 513, if the client device 130 has requested an opportunistic lock in the file open request, the file server 110 grants the opportunistic lock to the first client device 130 with a higher probability than the first client device 130 actually needs.

For example, when a CIFS first client device 130 opens a file 113 in read-only access mode and write-deny deny mode, the file server 110 associates that type of file locking with the file 113 . File server 110 also associates an opportunistic lock with file 113 having a read-write access mode and a deny-all deny mode.

At flow point 520 , file server 110 responds to a request from CIFS first client device 130 for a file lock on file 113 .

At flow point 530 , the second client device 130 attempts to open the file 113 .

In step 531, the file server 110 either receives a file open request from the second CIFS client device 130, or receives an NLM file lock request from a PC NFS client device 130.

As part of performing this step 531, while execution of the request by the second client device 130 interrupts the oplock and gets a response from the owner of the oplock, the first client device 130, the file server 110 suspends the opportunistic lock requested by the second client device 130. Execution of the client device 130 request.

At step 532, the file server 110 aborts the oplock by sending an "oplock interrupt" message 140 to the CIFS first client device 130.

This is already expected when the second client device 130 is a CIFS client device 130 . When the second client device 130 is an NFS client device 130, the file server 110 delays its response to the NFS (or NLM) protocol request message 140 until the CIFS first client device 130 responds to the "opportunistic lock break" message 140 .

In step 533, the CIFS first client device 130 receives the "opportunistic lock interrupt" message 140 and can respond to the message 140 in one of two ways:

CIFS first client device 130 is able to close file 113 (thus canceling the file lock associated with the file open): or

The CIFS first client device 130 can flush all pending CIFS write and byte range lock requests to the file 113 that are cached locally in the client device 130 (i.e. it can communicate the results of those file system operations to the file server 110 ), and delete the pre-read data of the obtained file 113. Since the second client device 130 may then write new data into the file to invalidate the read-ahead data, the read-ahead data should be deleted.

At step 534 , the file server 110 receives a response from the CIFS first client device 130 .

In step 535, the file server 110 determines whether the CIFS first client device 130 holds the file 113 open, and if so, compares the implicit lock mode requested by the second client device 130 with the new file lock status of the file 113. If the file server 110 determines that the request of the second client device 130 is allowed to proceed, the method continues to flow point 540 . If the file server 110 determines that the request of the second client device 130 is not allowed to proceed, the request is denied.

At flow point 540 , the file server 110 is ready to allow the request from the second client device 130 mentioned in step 531 .

How To (Change Notification Manager)

Fig. 6 shows a flowchart of a method of operating a change notification manager in a multi-protocol file server.

The method 600 of operating a change notification manager in a multi-protocol file server includes a set of process steps and flow points performed by the file server 110 in cooperation with at least one client device 130 .

At flow point 610 , file server 110 is ready to receive file server request message 140 .

In step 611 , the file server 110 receives a file open request message 140 from the first CIFS client device 130 while specifying a directory on the file server 110 . File server 110 determines that the file open request should be allowed and grants first CIFS client device 130 a CIFS file lock on the directory.

In step 612, the file server 110 receives a change notification request message referring to the opened directory from the first CIFS client device 130 to convert the file lock on the open directory to a change watch lock.

At step 613, the file server 110 converts the file lock on the open directory to a change watch lock on the specified directory.

At flow point 620, the "change watch" lock has been associated with the specified directory and is ready to notify the first CIFS client device 130 of changes to the directory.

In step 621, the file server 110 receives a file server request message 140 from the second client device 130, requesting a change to the specified directory, thereby causing the first client device 130 to notify the change (the type of change includes file generation, file deletion, naming, moving files between directories, changing file attributes, and changing file modification times). The file server request message 140 from the second client device 130 may be CIFS or NFS. The second client device 130 can be any one of the Unix NFS client device 201, the PC NFS client device 202 or the CIFS Windows client device 203.

In step 622, the file server 110 notifies the first client device 130 that holds the "change monitor" lock for the changes described in step 621, possibly including multiple items, each of which specifies the changed The name and change type of the file or subdirectory. If more than one such first client device 130 exists, the file server 110 notifies all first client devices.

Change notification is a known technique in the field of file locking under the Windows NT operating system environment. The technology is described in detail in the literature on the "Windows NT 4.0" operating system including, for example, the IETF specification for CIFS, available via the file cifs6.doc or cifs6. txt, obtained from Microsoft Corporation, Washington, Redmond, and used as a reference herein.

At flow point 630 , the file server 110 has notified the first CIFS client device 130 of the change to the specified directory and is ready for the next message 140 .

alternative embodiment

While a preferred embodiment has been disclosed, various modifications are possible and will become apparent to those skilled in the art upon a study of this specification which remain within the scope and concept of the invention. .

Technical Appendix

Additional and further information on the present invention is contained in a technical appendix accompanying this application. This technical appendix consists of 30 pages (including figures) and is hereby incorporated by reference.

Claims (38)

1. the method for a file server of an operation, described method is included in one group of customer equipment that uses multiple different file server or file locking agreement and puts teeth in a kind of step of unifying the file locking semantic relation.

2. the method for claim 1 is characterized in that described unified file locking semantic relation comprises the chance locking with following function:

Use first agreement to ask by first customer equipment; And

Second customer equipment that is different from second agreement of described first agreement by use causes the interruption that described chance locks.

3. method as claimed in claim 2 is characterized in that described first agreement comprises CIFS.

4. method as claimed in claim 2 is characterized in that described second agreement comprises NFS or NLM.

5. the method for claim 1 is characterized in that described unified file locking semantic relation comprises step:

According to first message of using the first described agreement, will license to the first described customer equipment to a chance locking that selects files; And

According to second message of using the second described agreement, interrupt described chance locking.

6. method as claimed in claim 5 is characterized in that described interrupt step comprises step:

According to described second message, send a chance locked interrupt message to described first customer equipment;

Postpone the execution of the indicated file system requests of described second message;

From the response of described first customer equipment reception to described chance locked interrupt message; And

After described receiving step, handle and respond described second message.

7. the method for claim 1 is characterized in that described unified file locking semantic relation comprises that the change with following function monitors lockType:

Use first agreement to ask by first customer equipment; And

Second customer equipment that is different from second agreement of described first agreement by use causes a Notification of Changes.

8. method as claimed in claim 7 is characterized in that described first agreement comprises CIFS.

9. method as claimed in claim 7 is characterized in that described second agreement comprises NFS.

10. the method for claim 1 is characterized in that described unified file locking semantic relation comprises step:

According to first message of using the first described agreement, will monitor that locking licenses to the first described customer equipment to the change of a selected catalogue; And

According to using the second described agreement and, sending a Notification of Changes message to described first customer equipment about second message of described selected catalogue.

11. the method for claim 1 is characterized in that the described step that puts teeth in comprises:

Discern multiple different agreement;

According to the message of having used at least a described agreement, provide a kind of unified file locking semantic relation; And

Force all described customer equipments to implement described unified file locking semantic relation.

12. method as claimed in claim 11 is characterized in that described unified file locking semantic relation comprises:

According to first message of using the first described agreement, will license to the first described customer equipment to a chance locking; And

According to second message of using the second described agreement, interrupt described chance locking.

13. method as claimed in claim 12 is characterized in that described interrupt step comprises:

Send a chance locked interrupt message according to described second message to described first customer equipment;

Postpone to carry out a file system requests by described second message indication;

From the response of described first customer equipment reception to described chance locked interrupt message; And

After receiving step, handle and respond described second message.

14. method as claimed in claim 11 is characterized in that the described step that puts teeth in described unified file locking semantic relation comprises:

According to from first customer equipment and use first message of described first agreement to authorize a change to monitor locking; And

Send a Notification of Changes message according to second message of using described second agreement to described first customer equipment.

15. method as claimed in claim 11 is characterized in that the described step that puts teeth in described unified file locking semantic relation comprises:

A selected message of described unified file locking semantic relation is violated in identification; And

Described selected message is made a errored response corresponding to the agreement relevant with described selected message.

16. method as claimed in claim 11 is characterized in that the described step that puts teeth in described unified file locking semantic relation comprises:

Identification is used to obtain to a selected message according to the bytes range locking of the file of described selected agreement, and described bytes range locking has a kind of lockType; And

Test resulting described bytes range locking whether with conflict with a kind of existing locking phase that message generated of or other agreement by using.

17. method as claimed in claim 11 is characterized in that the described step that puts teeth in described unified file locking semantic relation comprises:

Identification is used to open a selected message according to the file of described selected agreement, and described selected message comprises a kind of request access module; And

With by using whether test utilize the described request access module to open described file to conflict with a kind of existing locking phase that message generated of or other agreement.

18. method as claimed in claim 17 is characterized in that

Described selected message comprises a kind of request refusal pattern; And

Comprise test utilize described request refusal pattern open described file whether with by the afoul step of using with a kind of or other agreement of existing locking that message generated.

19. method as claimed in claim 11 is characterized in that the described step that puts teeth in described unified file locking semantic relation comprises:

Identification is used for a selected message that a file according to described selected agreement is read or write, and described selected message comprises a kind of request access module; And

Whether with by using test conflicts with a kind of existing locking phase that message generated of or other agreement to reading or writing of described file.

20. the method for claim 1 is characterized in that the described step that puts teeth in comprises:

Receive first message of using first agreement, described first message can be used for locking an at least a portion that selects files;

Receive to use second message of second agreement, described second message can be used for asking the visit to described part;

Described visit that more described second message is asked and described locking, and if described locking be under an embargo, then refuse described visit.

21. method as claimed in claim 20 is characterized in that described first agreement comprises CIFS.

22. method as claimed in claim 20 is characterized in that described first agreement or described second agreement comprise NLM.

23. method as claimed in claim 20 is characterized in that described second agreement comprises NFS.

24. method as claimed in claim 20 is characterized in that

The step of described second message of described reception comprises being used to discern and is used to obtain to a step according to one second message of the bytes range locking of the file of described second agreement that described bytes range locking has a kind of lockType; And

Described comparison step comprise be used to test resulting described bytes range locking with described lockType whether with by the afoul step of using with a kind of or other agreement of existing locking that message generated.

25. method as claimed in claim 24 is characterized in that described testing procedure is corresponding to being used for described second protocol of messages.

26. method as claimed in claim 24 is characterized in that described testing procedure works under described first agreement constantly at File Open, constantly then works under described second agreement in visit.

27. method as claimed in claim 24 is characterized in that described testing procedure works under described first agreement constantly at File Open, constantly then works under described second agreement in locking request.

28. method as claimed in claim 20 is characterized in that

The step of described second message of described reception comprises being used to discern and is used to open a step according to one second message of the file of described second agreement that described second message comprises a kind of request access module; And

Described comparison step comprise be used to test utilize the described request access module visit described file whether with by the afoul step of using with a kind of or other agreement of existing locking that message generated.

29. method as claimed in claim 20 is characterized in that

The step of described second message of described reception comprises and is used to discern the step that is used for one second message that a file according to described second agreement is read or write; And

Described comparison step comprise be used to test by described second message visit described file whether with by the afoul step of using with a kind of or other agreement of existing locking that message generated.

30. method as claimed in claim 20 is characterized in that

The step of described first message of described reception comprises the step that is used for authorizing according to described first message chance locking; And

Described comparison step comprises the step of interrupting described chance locking according to described second message.

31. method as claimed in claim 30 is characterized in that described interrupt step comprises:

Send a chance locked interrupt message according to described second message to described first customer equipment;

Postpone to carry out a file system requests by described second message indication;

From the response of described first customer equipment reception to described chance locked interrupt message; And

After receiving step, handle and respond described second message.

32. method as claimed in claim 31 is characterized in that the described response of described chance locked interrupt message is comprised a chance locked interrupt acknowledge message or a closing of a file message.

33. ten thousand methods as claimed in claim 1 is characterized in that described file locking semantic relation comprises according to the access module of being asked by first customer equipment that uses first agreement and refusal pattern and a definite locking mode.

34. the method for claim 1 is characterized in that described file locking semantic relation comprises:

According to the access module of asking and refusal pattern and the first definite locking mode by first customer equipment that uses first agreement;

According to the message of second customer equipment of second agreement that is different from described first agreement from use and the second definite locking mode;

More described first locking mode of wherein said file server and described second locking mode.

35. method as claimed in claim 34 is characterized in that the described locking compatibility matrix that relatively comprises.

36. method as claimed in claim 34 is characterized in that the described locking transformation matrix that relatively comprises.

37. method as claimed in claim 34 is characterized in that described second locking mode is in response to a bytes range locking request.

38. method as claimed in claim 34 is characterized in that described second locking mode is in response to the request of a NLM file locking.

Images