客户端缓存

我们缓存什么？

• 只读文件数据和目录数据
• 由客户机写入的数据

1. 什么时候写入服务器？
2. 如果客户机宕机了，会发生什么？

• 由其它机器写入的数据

1. 如何知道数据已经改变了？
2. 如何保持数据的一致性？

• 有没有预取？（不太理解）

如果我们进行缓存，这些风险将会使得事情不一致

使用缓存去减轻网络负载

• 其他客户端可以在推送时看到更新
• 如何使旧数据的缓存失效？

故障

1 服务器故障

• 数据在内存里，不在硬盘里。（丢失）
• 那么...如果客户端做了什么
  • seek() ; /* SERVER CRASH */; read()
  • If server maintains file position, this will fail. Ditto for open(), read()

2 丢失信息：要是我们失去了对delete("foo")的确认

• 与此同时，另一个客户创建了一个名为foo的新文件？

3 客户机宕机

• 客户端缓存也许会丢失数据

Client Caching in NFS v2

1. 缓存干净和脏的文件数据和文件属性
2. 客户端缓存中的文件属性在60秒后过期（文件数据不会过期）
3. 文件数据将根据文件属性中的修改时间进行检查（可能是缓存的副本）
   • 在一台机器上所做的更改最多可能需要60秒才能在另一台机器上反映出来

每当客户打开一个以前被关闭但（部分）被缓存的文件，客户必须马上使缓存的数据重新有效。这是通过检查文件最后被修改的时间并使包含过时数据的缓存无效来实现的。

4. 脏数据在客户端机器上被缓冲，直到文件关闭或长达30秒
   • 如果在此之前机器崩溃，则更改将丢失

Implication of NFS v2 Client Caching

1. 优点：如果打开/读取/写入/关闭可以在本地完成，则不会有网络流量。
2. 但… 数据一致性保证很差
   • 对于某些分布式应用程序来说简直是不可接受的
   • 生产力应用程序往往容忍这种松散的一致性
3. 通常，客户端不会在本地磁盘上缓存数据

NFS’s Failure Handling ——Stateless Server

1. 文件有状态，但是...
2. 服务器导出文件而不创建额外的状态
   • 没有“谁打开这个文件”的列表（打开文件上的每个操作的权限检查！）
   • 宕机后，没有"挂起的交易"
3. 崩溃恢复很“快”
   • 重启，让客户机们指出发生了什么
4. 状态藏在其他地方
   • Separate MOUNT protocol
   • Separate NLM locking protocol in NFSv4（Network Lock Manager）
5. Stateless protocol: requests specify exact state. read()
   ->read( [position]). no seek on server.

NFS’s Failure Handling

1. Operations are idempotent 操作是幂等的

• 我们如何确保这一点？ 文件/目录上的唯一ID。 它不是删除（“foo”），它是删除（1337f00f），其中该ID不会被重用。
• 并非完美 比如mkdir

2. 直写缓存：当文件关闭时，所有修改的块都发送到服务器。 close（）不会返回，直到字节安全地存储。

• Close failures?
  • 重试直到事情到达服务器
  • 返回失败给client

3. 大多数客户端应用程序无法处理close（）调用的失败。
4. 通常的选择：挂了很长时间试图联系服务器

NFS总结

• NFS provides transparent, remote file access
• Simple, portable, really popular
  (it’s gotten a little more complex over time, but...)
• Weak consistency semantics
• Requires hefty server resources to scale (write-through, server queried for lots of operations)

AFS

NFS缺陷

• 可能无法处理大规模
• 对网络延迟非常敏感

我们如何改进这？

1. 更积极的缓存（除了在内存中的AFS缓存在磁盘上）
2. 预取（在open的时候，AFS从服务器获取整个文件，使得后来的本地和快速操作）
   • 记住：对于传统的硬盘，大的顺序读取比小的随机写入要快得多。所以更容易支持（客户端a：读取整个文件;客户端B：读取整个文件），而不是让它们交替（alternate），特别是如果客户最终要读整个文件的话。

Client Caching in AFS

1. Callbacks！客户向服务器注册他们有文件副本;
   • 服务器告诉他们：“无效！”如果文件改变
   • 这交易状态改善一致性
2. 如果服务器崩溃怎么办？ 失去所有的回叫状态！
   • 重建来自客户端的回调信息：去问问大家“哪些文件被缓存了？
3. 如果客户机崩溃怎么办？
   • 必须重新验证它使用的任何缓存内容，因为它可能已经错过了回调

AFS v2 RPC Procedures

AFS特有的

1. Fetch：返回文件或目录的状态和可选的数据，并对其进行回调
2. RemoveCallBack：指定客户端从本地计算机刷新的文件
3. BreakCallBack：从服务器到客户端，撤销（revoke）文件或目录的回调
   • 如果回调被撤销，客户应该做什么？
4. Store：存储文件的状态和可选的数据

其他的和NFS类似

File Access Consistency

1. 在UNIX本地文件系统中，并发文件读写具有“顺序”一致性语义
   • 从用户级应用程序读取/写入的每个文件都是一个原子操作
     • 内核锁定文件vnode
   • 每个文件写入都立即对所有文件读取器可见
2. NFS和AFS都不提供这种并发控制

• NFS:有时在30秒内
• AFS:会话语义的一致性

AFS V2 的会话语义

1. 什么意思：
   • 文件写入对于立即在同一个框中进行处理是可见的，但对于其他机器上的进程不可见，直到文件关闭
   • 当文件关闭时，更改对新的打开可见，但对“旧”打开不可见
   • 所有其他文件操作立即可见
2. 实现：
   脏数据在客户端机器上被缓冲，直到文件关闭，然后被刷新回服务器，这导致服务器向其他客户端发送“中断回调”

AFS写入策略

1. 写回缓存
   • NFS的对面“每一个写都是神圣的”
   • 将块存储回服务器
     • 缓存溢出时
     • 在上次用户关闭（）
   • ..或不（如果客户端机器崩溃）
2. Is writeback crazy?
   Write conflicts “assumed rare”
   Who wants to see a half-written file?

AFS总结

1. 比NFS更低的服务器负载
   • 更多的文件缓存在客户端上
   • 回调：如果文件是只读的，则服务器不忙（通常情况下）
2. 但也许会慢一些：从本地磁盘访问比从另一台机器通过局域网的内存慢得多
3. 对彼此而言：

• 中央服务器是瓶颈：所有的读写操作至少一次;
• 是单点故障
• 使他们快速，健壮和可靠的服务器成本高昂。

命名空间建设与组织

1. 每一个客户端连接
   • Server: export /root/fs1/
   • Client: mount server:/root/fs1 /fs1
2. AFS： global name space
   • 命名空间被组织成卷
     • 全球目录 /afs
     • /afs/cs.wisc.edu/vol1/…; /afs/cs.stanford.edu/vol1/…
   • 每个文件都被识别为fid = <vol_id，vnode＃，唯一标识符>
   • 所有AFS服务器都保留“卷位置数据库”的副本，这是一个vol_id→server_ip映射表

Vol_id标识存储在单个服务器上的大量文件
Vnode＃提供并索引到服务器上的一个数组; 数组条目包含有关如何访问文件的信息

对位置透明度的影响

NFS:没有透明性

• 如果一个目录从一台服务器移动到另一台，客户端必须重新挂载
  AFS:透明性
• 如果卷从一台服务器移动到另一台服务器，则只需要更新服务器上的卷位置数据库

Naming in NFS

image.png

这里请注意，没有命名透明度，因为两个客户端都具有存储在不同层次命名空间中的文件（eg.mbox）。

image.png

用户认证和访问控制

1. 用户X登录到工作站A，想要访问服务器B上的文件
   • A怎么告诉B谁是X？
   • B应该相信A？
2. 在NFS V2中进行的选择
   • 所有服务器和所有客户端工作站共享相同的<uid，gid>名称空间->B将X的<uid，gid>发送给A
     • 问题：任何客户端工作站上的root访问都可能导致创建任意<uid，gid>的用户
   • 服务器无条件相信客户端工作站
     • 问题：如果任何客户端工作站被破坏，服务器上的数据保护将会丢失。
   • <uid，gid>以明文形式通过线路发送->请求数据包可以很容易伪造

用户认证（续）

1. 如何修改这些问题再NFS V2
   Hack 1: root remapping -> strange behavior
   Hack 2: UID remapping -> no user mobility
   Real Solution: use a centralized
   Authentication/Authorization/Access-control (AAA) system

A Better AAA System: Kerberos

1. 共享机密
   • 用户向KDC证明他是谁; KDC在客户端和文件服务器之间生成共享密钥

image.png

Kclient [S]表示使用客户端的私钥对S进行加密

Automounting

image.png
image.png