NFS客户端通过评估T-Tc <t来重新validation访问时的caching块。 如果失败，它会向NFS服务器发送一个getattr调用，请求相关文件的最后一个Tmodified标记。
AFS在周期性时间T后，在打开或重新启动时重新validation其caching文件。
当这些重新validation呼叫在networking中丢失时会发生什么？ 当我们假设使用NFS进行硬挂接时，NFS客户端是否等待getattr调用的回复，或者我们能否跳过这个检查，以便继续工作？
对于AFS同样，它是否阻止等待validation，还是我们可以继续工作？
OpenAFS和AuriStorFS采用的AFScaching一致性模型与您在问题中描述的有所不同。
存储在/ afs下的每个对象都有
每次对象的数据被修改时，对象的“数据版本号”都会递增，但当元数据发生更改时，则不会递增。
客户端，也就是cachingpipe理器，被允许caching对象的数据和元数据，但是只有当它已经从文件服务器获得了“callback承诺”时才被允许认为它是最新的，这是callback承诺的生命周期这决定了cachingpipe理器必须向文件服务器发出一个FetchStatus RPC的频率，只要callback承诺没有过期，cachingpipe理器就可以自由使用caching的数据，如果文件服务器向cachingpipe理器发出一个callback RPC，承诺被撤销，并且cachingpipe理器需要获取更新的状态信息。
原始安德鲁文件系统和OpenAFS中从文件服务器到cachingpipe理器的callback通道未经身份validation。 因此它不能用于传输实际数据或元数据的变化。 cachingpipe理器必须通过自己的连接获取该连接，这个连接有可能被authentication和encryption。 AuriStorFS和早期的AFS变体之间的差异之一是使用安全的callback通道。
cachingpipe理器获取最新的元数据后，可以将当前的数据版本号与caching的数据版本进行比较。 如果版本没有改变，那么caching的数据仍然有效。 否则，必须从caching中丢弃过期的数据，并且获取更新的数据。
AFScaching一致性模型的一个属性是文件系统被视为序列化消息传递平台。 一个基本的要求是，如果机器A正在使用一个文件，而机器B想要修改该文件，然后向机器A发送一个带外消息来读取文件更新在带外消息之前必须到达的更新文件。 通过确保在修改文件的RPC完成到颁发者之前所有的callback承诺被破坏，保证了该属性。
您提出了客户端和文件服务器之间的连接失败时会发生什么的问题。 文件服务器将尝试一段时间发送callbackRPC，但不会无限期地阻塞。 相反，它会为其无法到达的客户端排队延迟的回叫消息，并将RPC完成发行者。 下次丢失连接的客户端联系文件服务器时，其所有操作都将阻塞，直到所有延迟的callback被传递。
在连接丢失期间，客户端可以尝试与维护数据副本的另一个文件服务器进行通信。 如果没有被访问的卷被硬盘挂载，那么客户端将无限期地被阻塞。 如果它没有硬挂载，则任何发布的networkingRPC都将超时，失败将返回到发布应用程序。
我希望能够令人满意地描述AFS系列文件系统的行为。