Using projected timestamps to control the sequencing of file modifications in distributed filesystems

Abstract

It is not possible to maintain extremely tight synchronization of the time keeping clocks of the networked nodes comprising a distributed filesystem. However, when multiple client systems access the same file from different remote locations, a distributed consistency mechanism must ensure that all file read and write requests are only serviced from the latest version of the file. The current industry practice is to disable client-side caching when a concurrent write sharing condition arises (multiple clients active on the file and at least one of them writing). This forces all requests to flow through to the file server and consistency is maintained since all requests are then serviced from the same file image. The current practice sacrifices performance and scalability to maintain consistency. This document discloses methods for projecting and maintaining temporary filesystem timestamps that allow file read and write requests to be serviced from remote cached file images while still providing the same file consistency as the current industry practice. The temporary filesystem timestamps are updated to real filesystem timestamps whenever the client-side cache communicates with the file server.

What is claimed is: 
     
         1 . In a computing system where a data request has been passed between a file service proxy cache node and a downstream site, the file service proxy cache node being a network node located between a client system and the origin file system node, a non-transitory computer-readable storage medium including instructions that, when executed by the file service proxy cache node, performs the steps:
 dispatching a file access request to the downstream site;   receiving a response to the file access request, wherein the response includes:
 a version number of a file image cached at the downstream site; 
   comparing the version number of the file image cached at the downstream site to a version number of a file image cached at the file service proxy cache node;   if the version numbers are the same:
 continuing to use the file image cached at the file service proxy cache node; and 
   if the version numbers are different:
 setting the version number of the file image cached at the file service proxy cache node to the version number of the file image cached at the downstream site; 
 setting an arrival time to the file service proxy cache node's current time; and 
 resetting a delta time to zero. 
   
     
     
         2 . The system of  claim 1 , wherein the file service proxy cache node includes an origin file server. 
     
     
         3 . The system of  claim 1 , wherein the version number includes a last modification timestamp. 
     
     
         4 . The system of  claim 3 , wherein comparing the version number of the file image cached at the downstream site to the version number of the file image cached at the file service proxy cache node includes comparing the last modification timestamp of the file image cached at the downstream site to the last modification timestamp of the file image cached at the file service proxy cache node. 
     
     
         5 . The system of  claim 1  further comprising:
 if the connection to the downstream site is lost:
 reconnecting to the downstream site over the same path. 
 
 
     
     
         6 . The system of  claim 1  further comprising:
 if the connection to the downstream site is lost:
 reconnecting to the downstream site over a different path. 
 
 
     
     
         7 . The system of  claim 1  further comprising:
 if the connection to the downstream site is lost:
 flushing all file images that had been fetched through the failed path. 
 
 
     
     
         8 . The system of  claim 7  further comprising:
 including with the flush request the version number of the file image cached at the file service proxy cache node. 
 
     
     
         9 . In a computing system where a data request has been passed between a file service proxy cache node and a downstream site, the file service proxy cache node being a network node located between a client system and the origin file system node, a non-transitory computer-readable storage medium including instructions that, when executed by the file service proxy cache node, performs the steps:
 dispatching a file access request to the downstream site;   receiving a response to the file access request, wherein the response includes:
 a version number of a file image cached at the downstream site; 
   comparing the version number of the file image cached at the downstream site to a version number of a file image cached at the file service proxy cache node;   if the version numbers are the same:
 continuing to use the file image cached at the file service proxy cache node; 
   if the version numbers are different:
 setting the version number of the file image cached at the file service proxy cache node to the version number of the file image cached at the downstream site; 
 setting an arrival time to the file service proxy cache node's current time; and 
 resetting a delta time to zero; and 
   if the response to the file access request is not a flush response:
 discarding the current cached file image. 
   
     
     
         10 . The system of  claim 9  further comprising:
 determining if the file access request was processed by the downstream site without any errors. 
 
     
     
         11 . The system of  claim 10  further comprising:
 if the file access request was not processed by the downstream site without any errors, repeating the request to the downstream site. 
 
     
     
         12 . The system of  claim 10  further comprising:
 if the file access request was not processed by the downstream site without any errors, dispatching a file access request to a second downstream site. 
 
     
     
         13 . In a computing system where a flush request has been received at a file service proxy cache node from an upstream file service proxy cache node, the file service proxy cache node being a network node located between a client system and the origin file system node, a non-transitory computer-readable storage medium including instructions that, when executed by the file service proxy cache node, performs the steps:
 receiving a flush request from an upstream file service proxy cache node;   comparing the version number of the file image cached at the upstream site to the version number of the file image cached at the file service proxy cache node; and   if the version numbers do not differ:
 storing the received flush data in shadow extents; 
   determining if the file service proxy cache node is a server terminator site;   if the file service proxy cache node is a server terminator site:
 if all flush batches have been received and at least one of the flush batches has a data complete request flag set:
 determining whether synchronous write mode is being used for the file identified in the request; and 
 if synchronous write mode is being used:
 writing all file modifications to the underlying origin filesystem; 
 determining whether the write to the origin filesystem is successful; and 
 if the write to the origin filesystem is successful: 
  setting an all data received response flag and replacing all extents that have shadow extents with their respective shadow extents; 
  fetching the file's last modification timestamp from the origin filesystem; and 
  responding to the received flush request with a status code that indicates the successful completion of the request; and 
 
 
 if all flush batches have not been received:
 responding to the received flush request with a status code that indicates the successful completion of the request. 
 
   
     
     
         14 . The system of  claim 13  further comprising:
 if the file service proxy cache node is not a server terminator site:
 the file service proxy cache node flushing all file modifications downstream. 
 
 
     
     
         15 . The system of  claim 13  further comprising:
 if synchronous write mode is not being used:
 responding to the received flush request with a status code that indicates the successful completion of the request. 
 
 
     
     
         16 . The system of  claim 13  further comprising:
 if the write to the origin filesystem is not successful:
 responding to the upstream node with a status that indicates the type of error that occurred.