US 5,594,863 AGrant
Method and Apparatus for Network File Recovery
Issue Date:1997-01-14
•54 Claims
•13 Drawing Sheets
Abstract
A method and apparatus for assisting in file recovery after a network fault uses a block state indicator in a client cache. After file data is stored in the client cache, the block state indicator is set to a client-cached state. After the file data is stored in a server cache, the block state indicator is set to a server-cached state. After the file data is stored in a non-volatile store attached to the server, the block state indicator is set to a stored state. If the data in server cache is lost or compromised due to a network fault, the data maintained in client memory is retransmitted. In a similar manner, file locks and file semaphores are re-established after a network fault.
Metadata
Assignee
- Novell, Inc.
Inventor
- Ian J. Stiles
Application Information
Application Number:US 4949196
Filing Date:1995-06-26
Priority Date:1995-06-26
Art Unit:243
Classifications
IPC:
G01R 3128G06F 1100
Field of Search:
395364182.13;182.14243.41
Patent Drawings (13 sheets)
Description
Copyright Notice
A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
Field of the Invention
The present invention relates to the recovery of files in a computer network after a network fault that alters the contents of a file server's memory, and more particularly to a method and apparatus for recovering file data, file locks, and file semaphores by using a client computer's cache after a network fault.
Technical Background of the Invention
Personal computers or workstations may be linked in a computer network to allow the sharing of data, applications, files, and other resources. In a client/server network, the sharing of resources is accomplished through the use of a file server. The file server includes a processing unit that is dedicated to managing centralized resources and to sharing these resources with the personal computers and workstations, which are known as the "clients" of the server.
Each client includes a central processing unit ("CPU"), a memory which is directly accessible to the CPU, and one or more input/output ("I/O") devices such as a screen, keyboard, mouse, and the like. The client's memory may be battery-backed, but more often the memory is volatile memory (unbacked RAM) that loses data if power to the client is interrupted or if the client is rebooted. Some clients also have local non-volatile data stores, such as a local hard disk, while other clients have no local non-volatile store.
Each file server has a CPU, a volatile memory, various I/O devices, and at least one non-volatile data store. The non-volatile data store includes a controller and a non-volatile medium. To access the medium, the server's CPU sends read and write requests to the controller, which then attempts to carry out the request. Write requests are accompanied by file data which is destined for storage on the medium, or by a memory address identifying the present location of such data. Read requests are accompanied by a memory address which identifies memory destined to receive file data copied from the medium.
Thus, in the client/server network there are four locations that might reasonably be used to hold part or all of a file that is being used by a process which resides on a particular client: the server's non-volatile store, the server's memory, the client's non-volatile store, and the client's memory. Each location has relative advantages and drawbacks.
As noted, some clients do not have a local non-volatile store. Thus, the client store is not suitable for use as a necessary part of any general approach and will not be discussed further.
Storing file data on the server's non-volatile store is generally favored for several reasons. Placing file data on the server's store makes that data potentially accessible to all clients so that access is denied only as needed for security purposes. For this reason, the larger capacity stores in a network tend to be attached to the server, which in turn makes the server's store more attractive because more storage room is available (at least initially). In addition, keeping the file data on the server store prevents inconsistency because there is only one authoritative copy of the data.
However, placing all file data on the server's store typically decreases network performance. Before the client can read the file data, the data must be transferred by the controller from the non-volatile medium into the server's memory, and then the data must be transferred over the network to the client's memory. Both transfers take time. In particular, the transfer from non-volatile store to server memory tends to be very slow when compared to the time needed to read the same data from memory. Write operations incur similar delays.
Accordingly, many known systems "cache" file data by keeping a copy of the data in a region of the server's memory known as the "server cache." If a client reads data that happens to be in the server cache, no additional transfer from the non-volatile store is needed. Likewise, if a client writes file data that corresponds (i.e., is destined for the same position in the file) to data in the server cache, the new data can be simply written to the server's memory. The new data must be written to the non-volatile store eventually, but that transfer can be delayed until a later time if the controller is busy at present. The server can still avoid inconsistencies by coordinating its memory and non-volatile store usage to ensure that clients see only the most current copy of the data.
However, caching data in the server's memory does not eliminate the need to transfer that data over the network between the client and the server. The only way to eliminate the network transfer is to cache the data in a portion of the client's memory known as the "client cache." Unfortunately, client caching creates inconsistent versions of the cached data.
Consider the situation in which client A and client B each read the same data from the server into their respective client caches and then each modify the data differently without either client being informed that the other client is also modifying the data. If client C then reads the data from the server, C will get the old version instead of getting one of the more recent versions. Moreover, when the modified data is written back to the server for storage, the version that happens to be written last will overwrite the version that was written first. Thus, if A's data is written last, then B's changes will be lost and B will not be informed of the loss.
One solution is to claim exclusive control of the file or of the relevant portion of the file. This may be accomplished by locking the file so that only one client (or process) at a time is allowed to write to the file. If several files are needed, they may be claimed on an exclusive basis by setting a file semaphore. Thus, B may claim the file by locking the file or by setting the semaphore, make its changes, and then release the file by unlocking the file or by clearing the semaphore, as appropriate. A may then claim the file, overwrite B's changes, and then release the file. B's changes are still lost, but notification of the loss can be performed in connection with the file lock or semaphore operations so that B is informed. Moreover, a log of the changes can be maintained so that earlier versions of the data can be recovered at need. The log is updated each time the file is locked or unlocked, and each time a semaphore claiming the file is set or cleared.
Another approach to preventing inconsistencies caused by client caching is to force write requests all the way through to the server store each time they are made. Under this "write-through" approach, a process that writes data to the client cache is suspended until the controller commits the data to the non-volatile medium on the server and sends an acknowledgement of that committal back to the client. After the acknowledgement arrives, the process resumes and the region of client memory used to cache the data is considered free for other uses.
Thus, write-through minimizes the loss of data that is cached in the server but not yet committed to the store by preventing data from remaining in the server cache any longer than absolutely necessary before storage. Write-through allows logs and notifications similar to those associated with file locks and semaphores. Write-through also eliminates inconsistencies by placing all file data in one authoritative copy on the server's store.
However, because write-through effectively eliminates caching for writes, it may significantly decrease network performance. Suspending the process while waiting for the network and controller transfers to complete often increases the time required for the process to finish because the process could have been doing other work while these transfers were proceeding. Write-through also tends to increase the number of network and controller transfers. Under a cached approach, for instance, overwriting the same region of the file five times could result in the transfer of only the most recent copy of the data, whereas write-through would cause five network transfers and five transfers to the non-volatile store.
To improve system performance, some approaches consider the file data "written" as soon as the data reaches the server cache. Thus, the process is suspended only for the time needed to transfer the data across the network and to transfer an acknowledgement back to the client. The process is not forced to wait for an acknowledgement that the data has been transferred to the non-volatile medium. Likewise, the portion of client cache holding the data is considered free for re-use as soon as the server acknowledges receipt of the data.
However, treating data as written once it reaches the server cache leaves the data vulnerable to network faults. Network faults may occur as a result of hardware or software problems. Some network faults cause the server to reboot in the midst of a client process, thereby destroying any data in the server cache. Such data is lost if it has not yet been transferred from the server cache to the server store. Rebooting also eliminates file locks or semaphores held by the client.
Other network faults occur when a cable between the client and server is disconnected. The server regularly "pings" the client to determine if the client is still attached to the server. If the client does not respond to the server's ping after some predetermined period of time, the server logs the client off. From the client's point of view, being unilaterally logged off by the server causes many of the same problems as having the server suddenly reboot.
If the client treats data in the volatile server cache as being effectively written to the non-volatile server store, the client will not be informed after the cached data is damaged or lost. The client may even subsequently overwrite the only remaining copy of the data, which is in the client cache.
File locks and semaphores that are recorded only in server memory are also damaged or lost when a network fault occurs. The client process must either reconstruct the current locks and semaphores and then re-establish them with the server, or else lose the needed exclusive control. Unfortunately, many existing applications are not constructed to maintain an internal copy of the current locks and semaphores, nor are they constructed to restore those locks and semaphores after a network fault. As a result, locks and semaphores are not restored, files are corrupted, and data is lost.
In summary, considering data written once it reaches the server cache improves performance but leaves the data vulnerable to network faults that alter server memory. Using the write-through approach provides file integrity and reduces or eliminates data loss, but does so at a heavy performance cost. Both approaches leave client data vulnerable to the loss of file locks and semaphores.
Thus, it would be an advancement in the art to provide a method and apparatus for restoring file data after a network fault while still obtaining the performance benefits of caching data during at least some write operations.
It would also be an advancement to provide such a method and apparatus which assists in properly restoring the current file locks and semaphore settings after a network fault.
Such a method and apparatus are disclosed and claimed herein.
Brief Summary of the Invention
The present invention provides a method and apparatus for assisting in file recovery after a network fault. Unlike conventional approaches, which do not recover file data and related information from the memory of a client machine after a server connected to the client reboots, the present invention marks data as "grey" when it reaches the server's cache and as "clean" when it reaches the server's non-volatile store. Grey data is retransmitted to the server after a network fault.
Data can also be written-through to the server store, with the application that requests the write-through being suspended until it receives an acknowledgement that the data is safely stored. One write-through method of the present invention allows the application to continue before the acknowledgement by preserving a copy of the data in the client cache until the acknowledgement arrives.
File locks and semaphores for files and other network resources are likewise maintained in the client's memory so that they can be restored after the server recovers from the network fault. In this manner the present invention provides a method and apparatus for restoring files after a network fault while still obtaining the performance benefits of caching data during at least some write operations.
The features and advantages of the present invention will become more fully apparent through the following description and appended claims taken in conjunction with the accompanying drawings.
Brief Description of the Drawings
To illustrate the manner in which the advantages and features of the invention are obtained, a more particular description of the invention summarized above will be rendered by reference to the appended drawings. Understanding that these drawings only provide selected embodiments of the invention and are not therefore to be considered limiting of its scope, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:
FIG. 1 is a schematic illustration of a computer network.
FIG. 2 is a diagram illustrating embodiments of a client computer and a server computer in the computer network according to the present invention.
FIG. 3 further illustrates one embodiment of a server cache in the client computer.
FIG. 4 further illustrates one embodiment of a client cache in the client computer.
FIG. 5 illustrates a conventional client cache.
FIG. 6 is a flow chart illustrating a file data recovery method of the present invention.
FIG. 7 is a flow chart illustrating another file data recovery method of the present invention.
FIG. 8 is a flow chart illustrating another file data recovery method of the present invention.
FIG. 9 is a flow chart illustrating a write-through method of the present invention.
FIG. 10 is a flow chart illustrating an instance-creating method of the present invention.
FIG. 11 is a diagram illustrating the components of an instance identifier according to the present invention.
FIG. 12 is a flow chart illustrating a file lock recovery method of the present invention.
FIG. 13 is a diagram illustrating the components of a file lock identification according to the present invention.
FIG. 14 is a flow chart illustrating a semaphore recovery method of the present invention.
Detailed Description of the Preferred Embodiments
Reference is now made to the figures wherein like parts are referred to by like numerals. The present invention relates to a method and apparatus for assisting the recovery of files in a computer network after a network fault occurs. One of the many networks suited for use with the present invention is indicated generally at 10 in FIG. 1. In one embodiment, the network 10 includes Novell NetWare.RTM. software, version 4.x (NetWare is a registered trademark of Novell, Inc.). The illustrated network 10 includes several connected local networks 12. Each local network 12 includes a file server 14 connected by signal lines 16 to one or more clients 18. The clients 18 include personal computers and workstations. The signal lines 16 typically include twisted pair, coaxial, or optical fiber cables, but may also include transmission means such as telephone lines, satellites, and microwave relays. A printer 20 and an array of disks 22 are also attached to the network 10. Although a particular network 10 is shown, those of skill in the art will recognize that the present invention is also useful in a variety of other networks.
One server 14 and one client 18 are further illustrated in FIG. 2. The server 14 includes a network port 28 which allows the server 14 to read packets from, and write packets to, the signal line 16 that carries packets between the server 14 and the client 18. The network port 28 includes hardware and software familiar to those in the art, and the packets are organized, transmitted, and interpreted in a manner that is readily determined by those of skill in the art.
The server 14 also includes a server memory 30. Typical embodiments of the server memory 30 include random access memory chips ("RAM") which form a volatile data store. As used herein, a data store is considered "volatile" if the temporary interruption of electrical power flowing normally to the device causes alteration or loss of data stored in the device. Thus, typical RAM is volatile, but battery-backed RAM is non-volatile. Other familiar non-volatile stores include, without limitation, magnetic hard disks, magnetic floppy disks, optical disks, CD-ROM disks, and magnetic tape.
It is well known that each such data store includes a substrate such as a magnetic material which is capable of storing data in physical form. According to the present invention, the substrate of the server memory 30 is given a specific physical configuration that causes the server 14 to operate in the manner taught herein. A first portion of the server memory 30 stores a server operating system 32. The server operating system 32 includes familiar operating system capabilities. However, these familiar capabilities are supplemented, modified, and/or replaced in a manner readily determined by those of skill in the art by the file recovery capabilities of the present invention.
A second portion of the server memory 30 stores a server cache 34. In the illustrated embodiment, the server cache 34 is logically outside the server operating system 32. In alternative embodiments the server cache 34 is part of the server operating system 32.
The server 14 also includes a central processing unit ("CPU") 36. The CPU 36 may be any familiar CPU, including without limitation commercially available complex instruction set and reduced instruction set microprocessors. The CPU 36 may also be implemented as a set of connected multiprocessors.
In addition, the server 14 includes a non-volatile store 38. The non-volatile store 38 is often physically located near the CPU 36 and the server memory 34, but in some embodiments the non-volatile store 38 is accessed over a signal line 16. Thus, three separate portions of the disk array 22 in FIG. 1 could be the non-volatile stores 38, respectively, of the three servers 14 shown. Alternatively, the entire disk array 22 could be the non-volatile store 38 of a single server 14. Those of skill in the art will readily determine ways in which to make the non-volatile store 38 accessible to the server 14.
The non-volatile store 38 includes a controller 40 of a type familiar to those of skill in the art, such as a disk controller. The controller 40 is in control signal communication with the CPU 36 and in data transfer communication with the server cache 34. Thus, the CPU 36 is capable of sending read and write requests to the controller 40. A read request requests the controller to read data from a non-volatile medium 42 (such as a magnetic disk medium) and to place a copy of that data at a specified location in the server cache 34. A write request requests the controller to write data to the non-volatile medium 42 and to then acknowledge to the CPU 36 that the write has been completed. The write request includes either a copy of the data to be written or, more commonly, the address of a memory location within the server cache 34 where the data to be written is presently located. The manner in which read and write requests are made and acknowledged is generally familiar to those of skill in the art, but the generation of such requests according to the present invention is novel.
With continued reference to FIG. 2, the client 18 includes a network port 44, a CPU 46, and a client memory 48. The network port 44 in the client 18 may be identical to the network port 28 in the server, or may simply be compatible to the extent needed to transfer packets between the signal line 16 and the client memory 48. The CPU 46 in the client 46 may be identical to the server CPU 36, but need not be.
Each of the CPUs 36, 46 must be capable of being controlled by software in a manner that makes the computers 14, 18 operate according to the present invention. One embodiment of suitable controlling software written in the C programming language is provided in a Listing Appendix attached hereto. However, those of skill will readily determine embodiments of software for controlling the CPUs 36, 46 in C++, assembly, or any other familiar programming language, or in a combination of such languages.
In one embodiment, the client memory 48 includes RAM which is configured in three portions to control operation of the client computer 18. A first portion of the client memory 48 stores an application program 50. Application programs 50 include, without limitation, word processors, spreadsheets, database managers, and program development tools.
A second portion of the client memory 48 stores a client operating system 52. The client operating system 52 includes familiar operating system capabilities compatible with the needs of the application programs 50 and the capabilities of the server operating system 32. However, these familiar capabilities are supplemented, modified, and/or replaced in a manner readily determined by those of skill in the art by the file recovery capabilities of the present invention.
A third portion of the client memory 48 stores a client cache 54. In the illustrated embodiment, the client cache 54 is logically outside the client operating system 52. In alternative embodiments the client cache 54 is part of the client operating system 52.
With reference to FIGS. 2 and 3, one embodiment of the server cache 34 includes a plurality of server cache data blocks 60 and a corresponding plurality of dirty flags 62. Each server cache data block 60 is configured for temporary storage of a block of file data As used herein, "file data" includes, without limitation, file contents, directory information, name and address resolutions, and other data organized or used by an operating system or a file system. Thus, "file data" includes without limitation user-generated data and system structures maintained in familiar file systems such as the 12-bit and 16-bit File Allocation Table ("FAT") file systems first used by the MS-DOS.RTM. operating system (MS-DOS is a registered trademark of Microsoft Corporation), and analogous data maintained in the High Performance File System ("HPFS").
Those of skill in the art will readily determine both the appropriate size of each server cache data block 60 and the number of server cache data blocks 60 to locate within the server cache 34. Although the blocks 60 illustrated are in one large contiguous region of server memory 30, it will be appreciated that two or more separate regions of the memory 30 are used in other embodiments, with each separation between regions being aligned on a boundary 64 between two data blocks 60.
In some embodiments, the dirty flags 62 are all stored together as bits in an array of bits near one of the data blocks 60. In other embodiments, each dirty flag 62 is stored in a bit located physically near the data block 60 to which the flag 62 corresponds. In alternative embodiments, the dirty flags 62 are non-zero indexes or pointers in a list which holds the allocated data blocks; blocks which are still available are not referenced on the list. The list is typically arranged in LRU order, that is, with "least recently used" blocks near the front of the list. In some embodiments, each dirty flag 62 is represented as a pair of indexes which define a region of data, with the dirty flag 62 clean state occurring when the indexes define an empty region and the dirty state occurring when the indexes define a non-empty region.
With reference to FIGS. 2 and 4, one embodiment of the client cache 54 includes a plurality of client cache data blocks 70 and a corresponding plurality of client block state indicators 72. Each data block 70 is configured for temporary storage of a block of file data and for file data recovery according to the present invention. Those of skill in the art will readily determine both the appropriate size of each data block 70 and the number of data blocks 70 to locate within the client cache 54; neither the number of blocks nor the size of each block need equal the corresponding characteristics of the server cache 34. Although the blocks 70 illustrated are in one large contiguous region of client memory 48, it will be appreciated that two or more separate regions of the memory 48 are used in other embodiments, with each separation between regions being aligned on a boundary 74 between two data blocks 70.
In some embodiments, the block state indicators 72 are all stored together as two-bit bitfields in an array of bits near one of the data blocks 70. In other embodiments, each block state indicator 72 is stored in a bitfield physically near the data block 70 to which the indicator 72 corresponds. In alternative embodiments, the block state indicators 72 are non-zero indexes or pointers in two lists. One list holds client-cached block state indicators 72 corresponding to "dirty" data, while the other list holds server-cached block state indicators 72 corresponding to "grey" data. Blocks 70 which are available because they hold server-stored "clean" data are not referenced on either list.
In some embodiments, each block state indicator 72 is represented as two pair of indexes which define regions of data, with different block state indicator 72 states occurring according to whether the indexes define empty or non-empty regions. One pair of indexes defines a grey region, while the other pair of indexes defines a dirty region. When the grey region is non-empty, the block state indicator 72 is in the grey state. When the dirty region is non-empty but the grey region is empty, the block state indicator 72 is in the dirty state. When both regions are empty the block state indicator 72 is in the clean state. In the dirty, grey, and clean states, the block 70 contains valid read data. Prior to any read operations, the block 70 holds neither valid read nor valid write data and the block state indicator 72 is in an "unused" state.
With reference to FIGS. 2, 4, and 5, a conventional client cache 80 contains dirty flags 82 instead of the block state indicators 72 of the present invention. Each dirty flag 82 is capable of switching between a "dirty" state and a "clean" state. When a particular dirty flag 82 is in the clean state, a corresponding data block 84 holds valid read data (data read from the server 14) and is available to receive file data for writing to the server 14.
When the dirty flag 82 is in the dirty state, the corresponding block 84 holds valid read data but is not available to hold data being written to the server 14 because the block 84 already contains file data that needs to be written. File data needs to be written if it is intended for storage on the file server but the file server has not yet acknowledged receiving the data. Prior to any read operations, the dirty flag 82 is in an "unused" state because the block 84 holds neither valid read nor valid write data.
By contrast, each block state indicator 72 of the present invention is capable of switching between three states when the corresponding client data block 70 is in use; a fourth state indicates the block 70 is not in use. The three use states are known as the "client-cached" or "dirty" state, the "server-cached" or "grey" state, and the "server-stored" or "clean" state. Prior to any read operations, each client data block 70 is in an "unused" state, indicating that the block 70 holds neither valid read nor valid write data.
The client-cached state of the present invention is analogous to the dirty state of the conventional approach. A particular block state indicator 72 enters the client-cached state after a corresponding data block 70 receives file data for transfer to the server 14 (FIG. 1), as a particular dirty flag 82 enters the dirty state when its corresponding data block 84 receives file data for transfer to a server.
However, neither the server-cached state nor the server-stored state of the present invention are analogous to the clean state of the conventional approach. Some similarity does exist. A particular block state indicator 72 enters the server-cached state when data stored in a corresponding data block 70 is known to have arrived at the server 14, just as a particular dirty flag 82 enters the clean state when data stored in a corresponding data block 84 is known to have arrived at the server.
But the similarity is limited. Under the conventional approach, arrival of the data at the server makes the client data block 84 available to be re-used, that is, to be overwritten by other file data. By contrast, according to the present invention the client data block 70 is freed for re-use only after the block state indicator 72 enters the server-stored state. This occurs after the data is actually stored in the non-volatile store 38. Thus, the conventional approach treats data as stored once the data reaches the server cache, whereas the present invention distinguishes between data written in the server cache 34 and data written on the non-volatile medium 42.
Accordingly, the terms "dirty" and "clean" carry different meanings, depending on whether they are used in connection with a cache variable such as the dirty flag 62 of the server cache 34 or with a cache variable such as the block state indicator 72 of the client cache 54. The term "grey" carries meaning only in connection with the block state indicator 72 of the present invention; dirty flags 62, 82 are never in a grey state.
The present invention also provides methods for assisting the recovery of files after a network fault occurs. With reference to FIGS. 2, 4, and 6, one method of the present invention includes a step 90 of client-caching a specified piece of file data. The file data is specified by the application 50 in a write request, or by the operating system 52 in response to such a write request, in a manner familiar in the art.
The step 90 includes locating a block 70 that is unused or clean, as indicated by the corresponding block state indicator 72. If no such block 70 is initially available, one may be obtained by flushing to the server store 38 data held in another block 70 which is grey or dirty, thereby making the flushed block 70 available. Once an unused or clean block 70 is located, it is reserved by setting a flag, by altering the contents of an available blocks list, or by similar means readily determined by those of skill in the art. The file data is then copied into the reserved data block 70 by memcpy() or an analogous function.
One embodiment of software for controlling the client memory 48 according to the present invention includes the C typedef CacheBlock and the functions CBLink(), CBUnlink(), CBFree(), CBGetFree(), and CBReleaseOwner() shown in the attached Listing Appendix. These functions assist in maintaining an LRU list of data blocks 70, that is, a list in which the least-recently used blocks 70 are flushed to the store 38 first when space for more file data is needed in the client cache 54.
During an indicating step 92 the method then indicates that client-caching is complete by updating the block state indicator 72 corresponding to the data block 70 that now holds the file data. After the indicating step 92, the block state indicator 72 is in the client-cached state, also known herein as the "dirty" state.
As is usual in the computer programming art, the term "writing" is used herein to include without limitation both memory copying and memory moving steps. Memory copying copies data from one or more locations in RAM to other locations in RAM so that two copies of the copied data result, while memory moving data copies from one or more locations in RAM to at least one different location in RAM and frees at least some of the first locations so that only one reliable copy of the data results. "Writing" also includes copying and/or moving data between RAM and non-volatile media. "Updating" or "changing" a specified location in RAM or on non-volatile media includes writing over the location such that the data previously stored at the location is potentially altered. Those of skill in the art will readily determine appropriate implementations for particular writing or updating steps according to the present invention.
With reference to FIGS. 2, 3, 4, and 6, the method also includes a step 94 of server-caching the file data. The file data is server-cached by transmitting it over the signal line 16 to the server 14 and then writing the file data to an available server cache data block 60. A server cache data block 60 is available if its corresponding dirty flag 62 is in the clean state. All dirty flags 62 are placed in the clean state when the server computer 14 boots itself.
During another indicating step 96, the method then indicates that server-caching is complete by updating the block state indicator 72 corresponding to the data block 70 that held the file data that now resides in the server cache data block 60. After the indicating step 92, the block state indicator 72 is in the server-cached state, also known herein as the "grey" state. The dirty flag 62 corresponding to the server cache data block 60 holding the file data is set, thereby marking the block 60 as dirty to prevent the data from being inadvertently overwritten.
During a writing step 100, the server CPU 36 requests storage of the file data on the non-volatile store 38 by writing the file data to the controller 40. In some embodiments, the CPU 36 sends the controller 40 a copy of the file data. More often, however, the CPU 36 sends the controller 40 the address of the file data in the server memory 30 and the controller 40 reads the data from that location when the controller 40 is ready. In either case, under normal circumstances the file data is eventually written on the non-volatile medium 42.
During a receiving step 102, the server CPU 36 then receives an acknowledgement from the controller 40 indicating that the file data has been stored on the medium 42. In response, the server CPU 36 sends an acknowledgement across the signal line 16 to the client 18. The client 18 then performs another indicating step 104, after which the block state indicator 72 corresponding to the stored data is in the server-stored or "clean" state. The server 14 clears the corresponding dirty flag 62, thereby placing it in its clean state.
One embodiment of software for appropriately updating the block state indicators 72 according to the present invention includes the typedefs CacheBlock and FileInfoBlock, as well as the functions CBCleanDirt(), CBCleanGrey(), CBMakeDirty(), CBMakeGreyDirty(), FIBDirtyGreyCBs(), and FIBWhitenGreyCBs() shown in the attached Listing Appendix. The terms "whiten" and "clean" are used interchangeably.
In embodiments that have background flush processes or threads running, access to FileInfoBlock variables is controlled by the functions FIBCheckIn(), FIBCheckOut(), FIBBusyCheck() using semaphores or other familiar exclusion means. Exclusive access is gained by a successful call to FIBCheckOut(), which sleeps the caller until the FIB is available. FIBBusyCheck() is used to determine if the variable desired is available without sleeping the caller. Access is released by calling FIBCheckIn().
The steps 90 through 104 may be interrupted at any point by a network fault. The present invention provides several methods for recovering files after the network fault, each of which takes advantage of accomplished steps in the interrupted set of steps 90 through 104. Thus, with reference to FIGS. 2, 6, and 7, one method of the present invention includes a reconnecting step 112. During the reconnecting step 112, a network connection between the client 18 and the server 14 is re-established in a manner readily determined by those of skill in the art. One embodiment of software for reconnecting the client 18 and the server 14 according to the present invention includes the typedef QuickPath and the functions ReestablishConnection() and ReestablishDirsToConnection() shown in the attached Listing Appendix.
With reference to FIGS. 4, 6, and 7, a determining step 114 then determines that some block state indicator 72 is in the grey state. That is, the network fault occurred after the server-cached indicating step 96 but prior to the server-stored indicating step 104. During a changing step 116, the block state indicator 72 is changed back into the client-cached dirty state to flush the data through to the server store 38.
In one variant, flushing is accomplished by performing steps 94 through 104 with respect to the data in the data block 70 corresponding to the changed block state indicator 72, regardless of whether any of those steps were performed before the network fault. Unlike conventional approaches, the present invention thus sends the only good copy of the data to the rebooted server 14 rather than overwriting and losing that data.
One embodiment of software for flushing data from the client 18 to the server store 38 according to the present invention includes the typedefs CacheBlock and FileInfoBlock, as well as the functions CBFlush() and FIBFlush() shown in the attached Listing Appendix. The embodiment illustrated also includes a function BackgroundWriteBehind(), which the operating system 52 runs during at least some of the time the application 50 is blocked, suspended, or preempted, in order to flush client cache 54 data to the server store 38.
FIG. 8 illustrates a variant of the method shown in FIG. 7. A reconnecting step 122 reconnects the client 18 and server 14 as previously discussed. A re-establishing step 124 assures that the client 18 and the server 14 agree on which directories the client 18 is accessing. One embodiment of the step 124 includes the function ReestablishDirsToConnection() shown in the attached Listing Appendix.
With reference to FIGS. 2 and 8, a reopening step 126 reopens earlier instances of files, or creates new instances, as appropriate. One embodiment of the step 124 includes the function ReOpenCreateFile() shown in the attached Listing Appendix. In general, new instances are created whenever a first user wishes to save client-cached data but the file toward which the data was traveling when the network fault occurred was modified by a second user between the time the server 14 rebooted after the fault and the time the first user attempted to save the data once again on the server store 38.
One embodiment of the step 124 utilizes a CREATE.sub.-- VERIFY flag. During normal operation of the network 10, file creation operations may be requested of the server 14. The present invention detects such requests and sets the CREATE.sub.-- VERIFY flag for the specified file (e.g., in the FileInfoBlock) in the client memory 48. If a network fault follows the transmission of this creation request and precedes the arrival of an acknowledgement by the server 14 that the creation has been effected on the server store 38, and if a request to open the file after the client 18 reconnects to the server 14 fails because the file was not found, then the creation request will be retransmitted to the server 14. The risk is low that the file was intentionally deleted after the network fault but before the open request. The CREATE.sub.-- VERIFY flag is cleared only after the server 14 acknowledges that the file has been created on the store 38. One embodiment of the step 124 includes the function ReOpenCreateFile() shown in the attached Listing Appendix.
New file instances are truncated during the step 124 if a TRUNCATE.sub.-- VERIFY flag is set. During normal operation of the network 10, truncation operations which appear very similar to write operations may be requested of the server 14. For instance, a truncation operation may request a write of zero bytes at a given offset in a specified file. The present invention detects such requests and sets the TRUNCATE.sub.-- VERIFY flag for the specified file (e.g., in the FileInfoBlock) in the client memory 48. If a network fault follows the transmission of this truncation request and precedes the arrival of an acknowledgement by the server 14 that the truncation has been effected on the file on the server store 38, then the write request for zero bytes at the given offset will be retransmitted to the server 14. The TRUNCATE.sub.-- VERIFY flag is cleared only after the server 14 acknowledges that the file on the store 38 has been truncated. One embodiment of the truncation portion of step 124 includes the functions TruncateFile() and ReOpenCreateFile() shown in the attached Listing Appendix.
With reference to FIGS. 2, 4, and 8, a determining step 128 and a changing step 130 determine which block state indicators 72 are in the server-cached state and reset those indicators to the client-cached state, respectively. A flushing step 132 then sends the corresponding data from the client data blocks 70 to the server 14 once again, thereby ensuring that the data will not be lost as a result of the network fault.
An alternative method illustrated in FIGS. 2 and 9 allows use of the present invention in a "write-through" mode. At the high level of abstraction used by a typical application 50, the present invention's write-through mode appears similar to a conventional write-through. However, the present invention provides fault-recovery capabilities not found in conventional approaches.
Initially, the application 50 requests that specified file data be written-through to the server 14 during a requesting step 138. A suspending step 140 then suspends or "sleeps" the application 50. As a result, the application 50 stops and waits until it receives an acknowledgment that the data has been stored on the server store 38.
A sending step 142 sends the data from the client 18 to the server 14. The sending step 142 includes the steps 90 through 104 shown in FIG. 6. In some variants, the sending step 142 is followed by a signalling step 144 during which a "rush" signal corresponding to the file data is sent from the client 18 to the server 14. The rush signal reduces or eliminates the time during which the data is kept in the server cache 34 before being transferred to the controller 40. In one variant, the step 144 is used when a clean client cache data block 70 is needed but all client cache data blocks 70 are presently grey or dirty.
After the data is stored on the non-volatile medium 42, a resuming step 146 resumes execution of the application 50. The suspending step 140 and the resuming step 146 are accomplished by means familiar in the art. One embodiment of the write-through method of the present invention includes the global variable TrueCommit, which is set by users through an environment variable or similar means, as well as the function FILECommit() shown in the attached Listing Appendix.
FIGS. 2, 10, and 11 illustrate a variant of the present method which assists in recovering file data for one user when a file is modified by another user after a network fault occurs. A storing step 152 stores an instance identifier 154 of a predetermined file on the medium 42 in the server store 38. The illustrated embodiment of the instance identifier 154 includes a modification count 156 such as an integer or a long integer.
A connection identifier 158, a volume identifier 160, and a file identifier 162 are also part of the instance identifier 154. Suitable connection identifiers 158 include conventional identifiers supplied when the connection between the server 14 and the client 18 is made. Suitable volume identifiers 160 include conventional volume names. Suitable file identifiers 162 include conventional file names and file names concatenated with directory names. One embodiment of a file identifier includes the FileInfoBlock type illustrated in the Listing Appendix.
A client-caching step 164 corresponds to the client-caching step 90 and the indicating step 92 shown in FIG. 6. Likewise, a server-caching step 166 corresponds to the server-caching step 94 and the indicating step 96 of FIG. 6.
The first time it is performed, a creating/updating step 168 creates a copy of the instance identifier 154 in the client cache 54 by writing the values of the component parts 156 through 162 of the instance identifier 154 into the client memory 18. Subsequent performances of the step 168 update that copy of the instance identifier 154 each time a piece of file data is server-cached. Suitable updates include incrementing the modification count 156 by one; other increments or decrements are readily determined by those of skill in the art according to the present invention. Some variants of the present method store the instance identifier 154 within the client cache 54, while other variants store the instance identifier 154 in another part of the client memory 18. One suitable initial value for the modification count 156 is zero; other suitable values are readily determined.
An optional updating step 170 updates the copy of the instance identifier 154 on the server store 38 in connection with each update to the copy in client memory 48 during the creating-updating step 168. Variants of the present method reverse the relative order of the steps 168 and 170.
A comparing step 172 compares the copy of the instance identifier 154 located in the client memory 48 with the copy of the instance identifier 154 located on the server store 38 after a network fault. If the comparing step 172 determines that the two copies of the instance identifier 154 correspond to one another in a manner that indicates the file was not modified after the fault occurred, then it is safe to flush file data from the client cache 54 into the same instance of the file on the store 38.
One suitable comparing step 172 determines that the copies correspond if they contain the same value in each of the corresponding instance identifier components 156 through 162. However, the term "correspond" is used herein to indicate that strict equality is not required. For instance, one of skill could readily produce a variant in which corresponding copies differ by exactly N in their respective modification counts 156, where N is a predetermined positive integer.
If the comparing step 172 determines that the copies of the instance identifier 154 do not correspond, the user is notified that the file was modified by another user after the network fault and before all changes could be propagated from the client 18 to the server store 38. One suitable comparing step 172 determines that the copies do not correspond if their respective modification counts 156 differ.
In one variant, the user is given the option of saving the file data presently cached in the client cache 54 in a new instance of the file. In another variant, the invention automatically creates new instances using file names derived from the old instances. If no new file instance is authorized, the data is lost. But if the user wishes to create a new instance, or if the invention is configured to automatically create a new instance, that instance is created substantially as discussed in connection with the recreating and truncating step 126 shown in FIG. 8.
Regardless of whether the data is flushed to the original instance of the file or to a new instance, several variants are available. One variant flushes the data by performing at least the server-caching step 94, updating step 96, writing step 100, and receiving step 102 of FIG. 6, regardless of whether any of these steps were also performed before the network fault occurred. Another variant performs a conventional write-through on the data, while a third variant performs a write-through according to the present invention as illustrated and discussed in connection with FIG. 9.
With reference to FIGS. 2, 12, and 13, the present invention assists not only in the recovery of file data but also in the recovery of file locks. According to one method of the present invention, a storing step 178 stores a lock identification 180 of a file in the client memory 48. Suitable lock identifications 180 include a file identification 182 and a list of one or more lock regions 184. Suitable file identifications 182 include the components 158 through 162 shown in FIG. 11.
One suitable lock region 186 is specified by the starting offset 188 in the file of the beginning of the lock region 186 in combination with the length 190 of the lock region 186. Another suitable lock region 192 is specified by the starting offset 188 and by the ending offset 194. Other suitable lock regions 184 are readily determined by those of skill in the art.
As an optimization, one embodiment of the present invention uses "lock leases," which are quasi-locks maintained internally within either or both of the caches 34 and 54. A lock lease is applied to a file which is flagged as sharable but which is currently not being shared. A lock lease is released if a second process or user begins using the file. A lock lease is also released under circumstances when a file lock would be released, such as when the file is closed. Caching files which are flagged as sharable and are thus nominally not cachable is termed "opportunistic caching."
A reconnecting step 196 reconnects the client 18 to the server 14 after a network fault occurs. Suitable reconnection methods and systems are readily determined by those of skill in the art.
A re-establishing step 198 then re-establishes the lock(s) identified by the lock identification 180 by resubmitting the lock to the server 14 in a manner readily determined by those of skill in the art. Lock leases are handled internally by the client cache 54 and/or the server cache 34, and are not submitted as locks to the server operating system 32. A determining step 202 then determines that the block state indicator 72 (FIG. 4) corresponding to the file data is grey, namely, that the file data has been server-cached but not server-stored. A changing step 204 then changes the grey block state indicator 72 to dirty so that the file data will be flushed through to the server store 38.
With reference to FIGS. 2 and 14, the present invention assists not only in the recovery of file data but also in the recovery of semaphores. According to one method of the present invention, a storing step 210 stores a semaphore identification 180 in the client memory 48. Suitable semaphore identifications 180 include conventional semaphores controlling use of one or more files, printers, devices, ports, programs, objects, or other network resources. A reconnecting step 212 reconnects the client 18 to the server 14 after a network fault occurs. Suitable reconnection methods and systems are readily determined by those of skill in the art. A resubmitting step 214 then resubmits to the server 14 the semaphore(s) identified by the semaphore identification, thereby attempting to reclaim the resource(s) identified in the semaphore identification for exclusive use by the application 50.
Those of skill will appreciate that preferred embodiments of the present invention report errors and other conditions which interfere with the invention as it assists users in recovering files. One embodiment of the invention uses the function CantRedoFile(), shown in the attached Listing Appendix, to report predetermined errors. Other suitable error reporting and recovery means are readily determined by those of skill.
With reference to all Figures, articles of manufacture within the scope of the present invention include a computer-readable storage medium in combination with the specific physical configuration of a substrate of the computer-readable storage medium. The substrate configuration represents data and instructions which cause the computers 14 and 18 to operate in a specific and predefined manner as described herein. Suitable storage devices include floppy disks, hard disks, tape, CD-ROMs, RAM, and other media 11 (FIG. 1) readable by one or more of the file servers 14 and client computers 18. Each such medium tangibly embodies a program, functions, and/or instructions that are executable by the machines 14 and/or 18 to perform file data, file lock, and/or semaphore recovery steps of the present invention substantially as described herein.
Although particular apparatus and article embodiments of the present invention are expressly illustrated and described herein, it will be appreciated that additional and alternative apparatus and article embodiments may be formed according to methods of the present invention. Similarly, although particular method steps of the present invention are expressly described, those of skill in the art may readily determine additional and alternative steps in accordance with the apparatus and articles of the present invention. Unless otherwise expressly indicated, the description herein of methods of the present invention therefore extends to corresponding apparatus and articles, and the description of apparatus and articles of the present invention extends likewise to corresponding methods.
The invention may be embodied in other specific forms without departing from its essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. Any explanations provided herein of the scientific principles employed in the present invention are illustrative only. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope. ##SPC1##
Claims
What is claimed and desired to be secured by patent is:
1. A method for assisting the recovery of files in a computer network after a network fault occurs, the network including a file server and a client connected to the file server, the client including a client cache data block and a corresponding client block state indicator, the file server including a server cache data block and a non-volatile store, the non-volatile store including a controller and a non-volatile medium, said method comprising the following steps in the order indicated: client-caching a specified piece of file data by writing the file data to the client cache data block; indicating that client-caching is complete by updating the client block state indicator; server-caching the file data by writing the file data to the server cache data block; indicating that server-caching is complete by updating the client block state indicator; requesting storage of the file data by writing the file data to the controller in the file server; receiving an acknowledgement from the controller that the file data has been stored on the non-volatile medium; and indicating that storing is complete by updating the client block state indicator.
2. The method of claim 1, further comprising the steps of: reconnecting the client to the file server after the network fault occurs; determining that the client block state indicator indicates that server-caching is complete and that storing is not complete; and changing the client block state indicator to indicate instead that client-caching is complete and that server-caching is not complete.
3. The method of claim 2, wherein said reconnecting step is followed by the step of re-establishing a client directory with the server.
4. The method of claim 2, wherein said reconnecting step is followed by the step of re-opening a file that is stored on the server store.
5. The method of claim 2, wherein said reconnecting step is followed by the step of creating a new instance of a file that is stored on the server store.
6. The method of claim 2, wherein said reconnecting step is followed by the step of truncating a file that is stored on the server store.
7. The method of claim 1, wherein the network fault occurs after said step of indicating that server-caching is complete and before said step of indicating that storing is complete, and wherein said method further comprises the following steps after said step of indicating that server-caching is complete and before said step of indicating that storing is complete: reconnecting the client to the file server; and then trying again to store the file data by performing said steps of server-caching, indicating that server-caching is complete, requesting storage, and receiving an acknowledgement, regardless of whether any of said steps were also performed before the network fault occurred.
8. The method of claim 1, wherein said client-caching step occurs in response to a disk write-through requesting step by a process that resides on the client, and said method further comprises the steps of: suspending execution of the process after said disk write-through requesting step; and resuming execution of the process after said step of indicating that storing is complete.
9. The method of claim 8, further comprising the step of sending the file server a rush signal corresponding to the file data, the rush signal being sent before said resuming step.
10. The method of claim 1, wherein the file data is destined for storage in a file on the non-volatile medium in the file server, and said method further comprises the steps of: storing an instance identification of the file on the non-volatile medium in the file server; updating an instance identification of the file in the client cache after said server-caching step; and comparing the instance identification in the client cache with the instance identification stored on the non-volatile medium after a network fault occurs to determine whether the instance identifications correspond to one another.
11. The method of claim 10, further comprising the step of updating the instance identification stored on the non-volatile medium after said step of receiving an acknowledgement from the controller, said updating making the instance identification on the non-volatile medium correspond to the instance identification in the client cache.
12. The method of claim 10, wherein said steps of storing an instance identification and updating an instance identification comprise storing a modification count and updating a modification count, respectively.
13. The method of claim 10, wherein said comparing step determines that the instance identifications do not correspond to one another and that the file was not modified after the network fault occurred, and wherein said method further comprises the step of trying again to store the file data by performing said steps of server-caching, indicating that server-caching is complete, requesting storage, and receiving an acknowledgement, regardless of whether any of said steps were also performed before the network fault occurred.
14. The method of claim 10, wherein said comparing step determines that the instance identifications do not correspond to one another and that the file was modified after the network fault occurred, and wherein said method further comprises the step of storing the file data in a new instance of at least a portion of the file.
15. The method of claim 14, wherein said step of storing the file data in a new instance comprises performing said steps of server-caching, indicating that server-caching is complete, requesting storage, and receiving an acknowledgement, regardless of whether any of said steps were also performed before the network fault occurred.
16. The method of claim 1, wherein the file data is destined for storage in a file on the non-volatile medium in the file server, and said method further comprises the steps of: storing a lock identification of the file in the client, the lock identification identifying at least one lock region of the file; reconnecting the client to the file server after a network fault occurs; and then relocking the lock region of the file.
17. The method of claim 16, wherein said relocking step is followed by the steps of: determining that the client block state indicator indicates than server-caching is complete and that storing is not complete; and changing the client block state indicator to indicate instead that client-caching is complete and that server-caching is not complete.
18. The method of claim 16, wherein said relocking step is followed by the step of performing said steps of server-caching, indicating that server-caching is complete, requesting storage, and receiving an acknowledgement, regardless of whether any of said steps were also performed before the network fault occurred.
19. The method of claim 1, further comprising the steps of: storing a semaphore identification in the client, the semaphore identification identifying at least one resource which is claimed by a process residing on the client; reconnecting the client to the file server after a network fault occurs; and then resubmitting the semaphore identification to the file server to reclaim at least one resource after a network fault occurs.
20. An apparatus for assisting the recovery of files in a computer network after a network fault occurs, said apparatus comprising: a file server having a non-volatile store; a client connected to the file server by at least a portion of the network; a client cache in the client, the client cache including a client cache data block for holding a piece of file data and a corresponding block state indicator; a server cache in the server, the server cache including a server cache data block for holding the file data and a corresponding dirty flag; client-cached updating means for updating the block state indicator to indicate that client-caching is complete after the file data is written to the client cache data block; server-cached updating means for updating the block state indicator to indicate that server-caching is complete after the file data is written to the server cache data block; and server-stored updating means for updating the block state indicator to indicate that server-storing is complete after the file data is written to the server store.
21. The apparatus of claim 20, further comprising: means for reconnecting the client to the file server after the network fault occurs; means for determining that the block state indicator indicates that server-caching is complete and that storing is not complete; and means for changing the client block state indicator to indicate instead that client-caching is complete and that server-caching is not complete.
22. The apparatus of claim 21, further comprising means for creating a new instance of a file that is stored on the server store.
23. The apparatus of claim 20, further comprising: means for reconnecting the client to the file server and means for flushing the file data from the client cache through the server cache to the server store.
24. The apparatus of claim 20, further comprising: disk write-through requesting means capable of being called by a process that resides on the client; means for suspending execution of the process in response to a call to said disk write-through requesting means; and means for resuming execution of the process after storing of the file data on the server store is complete.
25. The apparatus of claim 24, further comprising means for sending the file server a rush signal corresponding to the file data.
26. The apparatus of claim 20, further comprising: means for storing an instance identification of the file on a non-volatile medium in the file server; means for updating an instance identification of the file in the client cache after server-caching the file data; and means for comparing the instance identification in the client cache with the instance identification stored on the non-volatile medium after a network fault occurs to determine if the instance identifications correspond to one another.
27. The apparatus of claim 26, further comprising means for updating the instance identification stored on the non-volatile medium after receiving an acknowledgement that the file data is stored on the server store, such that the instance identification on the non-volatile medium corresponds to the instance identification in the client cache.
28. The apparatus of claim 26, wherein said means for storing an instance identification and said means for updating an instance identification comprise means for storing a modification count and means for updating a modification count, respectively.
29. The apparatus of claim 26, further comprising means for flushing the file data from the client cache through the server cache to the server store.
30. The apparatus of claim 26, further comprising means for storing the file data in a new instance of at least a portion of the file.
31. The apparatus of claim 20, further comprising: means for storing a lock identification of a file in the client, the lock identification identifying at least one lock region of the file; means for reconnecting the client to the file server after a network fault occurs; and means for relocking the lock region of the file.
32. The apparatus of claim 31, wherein said means for relocking comprises: means for determining that the block state indicator indicates that server-caching is complete and that storing is not complete; and means for changing the block state indicator to indicate instead that client-caching is complete and that server-caching is not complete.
33. The apparatus of claim 31, further comprising means for flushing the file data from the client cache through the server cache to the server store.
34. The apparatus of claim 20, further comprising: means for storing a semaphore identification in the client, the semaphore identification identifying at least one resource which is claimed by a process residing on the client; means for reconnecting the client to the file server after a network fault occurs; and means for resubmitting the semaphore identification to the file server to reclaim at least one resource after a network fault occurs.
35. A computer-readable storage medium having a configuration that represents data and instructions which cause a client and a file server to perform method steps for assisting the recovery of files after a network fault occurs, the client connected to the server in a computer network, the client including a client cache data block and a corresponding client block state indicator, the file server including a server cache data block and a non-volatile store, the non-volatile store including a controller and a non-volatile medium, the method comprising the following steps in the order indicated: client-caching a specified piece of file data by writing the file data to the client cache data block; indicating that client-caching is complete by updating the client block state indicator; server-caching the file data by writing the file data to the server cache data block; indicating that server-caching is complete by updating the client block state indicator; requesting storage of the file data by writing the file data to the controller in the file server; receiving an acknowledgement from the controller that the file data has been stored on the non-volatile medium; and indicating that storing is complete by updating the client block state indicator.
36. The storage medium of claim 35, further comprising the steps of: storing a semaphore identification in the client, the semaphore identification identifying at least one resource which is claimed by a process residing on the client; reconnecting the client to the file server after a network fault occurs; and then submitting the semaphore identification to the file server to reclaim at least one resource after a network fault occurs.
37. The storage medium of claim 35, further comprising the steps of: reconnecting the client to the file server after the network fault occurs; determining that the client block state indicator indicates that server-caching is complete and that storing is not complete; and changing the client block state indicator to indicate instead that client-caching is complete and that server-caching is not complete.
38. The storage medium of claim 37, wherein the reconnecting step is followed by the step of re-establishing a client directory with the server.
39. The storage medium of claim 37, wherein the reconnecting step is followed by the step of re-opening a file that is stored on the server store.
40. The storage medium of claim 37, wherein the reconnecting step is followed by the step of creating a new instance of a file that is stored on the server store.
41. The storage medium of claim 37, wherein the reconnecting step is followed by the step of truncating a file that is stored on the server store.
42. The storage medium of claim 35, wherein the network fault occurs after the step of indicating that server-caching is complete and before the step of indicating that storing is complete, and wherein the method further comprises the following steps after the step of indicating that server-caching is complete and before the step of indicating that storing is complete: reconnecting the client to the file server; and then trying again to store the file data by performing the steps of server-caching, indicating that server-caching is complete, requesting storage, and receiving an acknowledgement, regardless of whether any of those steps were also performed before the network fault occurred.
43. The storage medium of claim 35, wherein the client-caching step occurs in response to a disk write-through requesting step by a process that resides on the client, and the method further comprises the steps of: suspending execution of the process after the disk write-through requesting step; and resuming execution of the process after the step of indicating that storing is complete.
44. The storage medium of claim 43, further comprising the step of sending the file server a rush signal corresponding to the file data, the rush signal being sent before the resuming step.
45. The storage medium of claim 35, wherein the file data is destined for storage in a file on the non-volatile medium in the file server, and the method further comprises the steps of: storing an instance identification of the file on the non-volatile medium in the file server; updating an instance identification of the file in the client cache after the server-caching step; and comparing the instance identification in the client cache with the instance identification stored on the non-volatile medium after a network fault occurs to determine whether the instance identifications correspond to one another.
46. The storage medium of claim 45, further comprising the step of updating the instance identification stored on the non-volatile medium after the step of receiving an acknowledgement from the controller, the updating making the instance identification on the non-volatile medium correspond to the instance identification in the client cache.
47. The storage medium of claim 45, wherein the steps of storing an instance identification and updating an instance identification comprise storing a modification count and updating a modification count, respectively.
48. The storage medium of claim 45, wherein the comparing step determines that the instance identifications do not correspond to one another and that the file was not modified after the network fault occurred, and wherein the method further comprises the step of trying again to store the file data by performing the steps of server-caching, indicating that server-caching is complete, requesting storage, and receiving an acknowledgement, regardless of whether any of those steps were also performed before the network fault occurred.
49. The storage medium of claim 45, wherein the comparing step determines that the instance identifications do not correspond to one another and that the file was modified after the network fault occurred, and wherein the method further comprises the step of notifying a user that the file was modified.
50. The storage medium of claim 45, wherein the comparing step determines that the instance identifications do not correspond to one another and that the file was modified after the network fault occurred, and wherein the method further comprises the step of storing the file data in a new instance of at least a portion of the file.
51. The storage medium of claim 50, wherein the step of storing the file data in a new instance comprises performing the steps of server-caching, indicating that server-caching is complete, requesting storage, and receiving an acknowledgement, regardless of whether any of those steps were also performed before the network fault occurred.
52. The storage medium of claim 35, wherein the file data is destined for storage in a file on the non-volatile medium in the file server, and the method further comprises the steps of: storing a lock identification of the file in the client, the lock identification identifying at least one lock region of the file; reconnecting the client to the file server after a network fault occurs; and then relocking the lock region of the file.
53. The storage medium of claim 52, wherein the relocking step is followed by the steps of: determining that the client block state indicator indicates that server-caching is complete and that storing is not complete; and changing the client block state indicator to indicate instead that client-caching is complete and that server-caching is not complete.
54. The storage medium of claim 52, wherein the relocking step is followed by the step of performing the steps of server-caching, indicating that server-caching is complete, requesting storage, and receiving an acknowledgement, regardless of whether any of those steps were also performed before the network fault occurred.
Patent Citations (30)
| Patent | Date | Inventor | Cited By |
|---|---|---|---|
| US4164017 | 1979-08-01 | Randell | |
| US4622631 | 1986-11-01 | Frank | |
| US4713755 | 1987-12-01 | Worley, Jr. | |
| US4755930 | 1988-07-01 | Wilson, Jr. et al. | |
| US4819159 | 1989-04-01 | Shipley | |
| US4858111 | 1989-08-01 | Steps | |
| US4939641 | 1990-07-01 | Schwartz | |
| US4989134 | 1991-01-01 | Shaw | |
| US5097409 | 1992-03-01 | Schwartz | |
| US5113519 | 1992-05-01 | Johnson | |
| US5119485 | 1992-06-01 | Ledbetter, Jr. et al. | |
| US5155824 | 1992-10-01 | Edenfield | |
| US5157663 | 1992-10-01 | Major et al. | |
| US5193162 | 1993-03-01 | Bordsen | |
| US5202969 | 1993-04-01 | Sato et al. | |
| US5218695 | 1993-06-01 | Noveck | |
| US5257370 | 1993-10-01 | Letwin | |
| US5261051 | 1993-11-01 | Madsen et al. | |
| US5276840 | 1994-01-01 | Yu | |
| US5276867 | 1994-01-01 | Kenley | |
| US5295259 | 1994-03-01 | Horne | |
| US5353410 | 1994-10-01 | Macon, Jr. et al. | |
| US5386540 | 1995-01-01 | Young et al. | |
| US5408644 | 1995-04-01 | Schneider et al. | |
| US5452447 | 1995-09-01 | Nelson | |
| US5488731 | 1996-01-01 | Mendelsohn | |
| US5493728 | 1996-02-01 | Solton | |
| US5504883 | 1996-04-01 | Coverston | |
| US5513314 | 1996-04-01 | Kandasamy | |
| US5542066 | 1996-07-01 | Mattson et al. |
Non-Patent Literature (5)
- "Distributed Operating Systems", Tanenbaum, pp. 154-156, 245-307, Prentice Hall, 1995.
- "Design and Implementation Details of the Windows NT Virtual Block Manager", Custer, Microsoft Systems Journal, Jul. 1995, pp. 67-79.
- "Operating Systems Concepts", Silberschatz et al., Fourth Edition, pp. 43-45, 525-569, 646-647, Addison-Wesley Publishing Company, 1994.
- "Netware 4 for Professionals", Bierer et al., pp. 585-607, 637-638, 643-645, New Riders Publishing, 1993.
- "Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency", Gray et al., pp. 202-210, ACM, 1989.