Method and apparatus for network file recovery

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.