MIT6.824 Lec11 Frangipani

背景

应用背景

workstations in offices，most file access is to user’s own files，need to potentially share any file among any workstations

特点

Frangipani具有以下设计特点：

• strong consistency
• caching in each workstation
• most complexity is in clients, not the shared Petal servers

cache coherence

基本机制

lock server：每个file会有对应的lock，记录持有人。

file  owner
-----------
x     WS1
y     WS1

Frangipani workstation：记录所持有lock的状态。

file/dir  lock  content
-----------------------
x         busy  ...
y         idle  ...

如果workstation持有lock，则包含两种状态：

• busy：using data right now
• idle：holds lock but not using the cached data right now

workstation lock rules：

• don’t cache unless you hold the lock
• acquire lock, then read from Petal
• write to Petal, then release lock

coherence protocol messages:

request  (WS -> LS)
grant (LS -> WS)
revoke (LS -> WS)
release (WS -> LS)

优化策略： workstation并不主动release lock，而是当lock server发送revoke后才进行release，因为同一个WS对同一个文件的读写操作很大概率是连续出现的。

实例

example: WS1 changes file z, then WS2 reads z

WS1                      LS            WS2
read z
--request(z)-->
                       owner(z)=WS1
                      <--grant(z)---
(read+cache z data from Petal)
(modify z locally)
(when done, cached lock in state)
                                       read z
                               <--request(z)--
   		              <--revoke(z)--
(write modified z to Petal)
--release(z)-->
                       owner(z)=WS2
                      --grant(z)-->
                                   (read z from Petal)

在workstation释放锁之前，必须保证所有的cache update已经写入petal和metadata。

atomicity

challenge：如果多个workstation在相同时间创建相同的文件，未完成的并发写操作是否可见？如文件创建的初始化inode，添加目录等行为。

Frangipani实现了transactional file-system operations，当对文件进行操作时，会获取所有受到影响的file lock。 只有当操作完成后，才会释放对应的file lock，因此不会出现未完成操作可见的情况。

crash recovery

Frangipani使用WAL来进行crash recovery，在将cache update写入petal前，会先将log写入petal。Frangipani WAL具有以下特点：

• Frangipani has a separate log for each workstation this avoids a logging bottleneck, eases decentralization but scatters updates to a given file over many logs
• Frangipani’s logs are in shared Petal storage, not local disk WS2 can read WS1’s log to recover from WS1 crashing
• just contains meta-data updates, not file content updates

Frangipani中的log由以下部分组成：

• log sequence number
• block #, new version #, addr, new bytes

当Frangipani收到lock server的revoke信息后，需要执行以下操作：

1. force its entire log to Petal
2. send the cached updated blocks to Petal
3. release the locks to the LS

如果当WS1在持有锁的过程中crash，且WS2请求该锁，则会发生什么：

1. LS sends revoke to WS1, gets no response
2. LS times out, tells WS2 to recover WS1 from its log in Petal
3. WS2 Read WS1’s log from Petal
4. WS2 Perform Petal writes described by logged operations
5. WS2 Tell LS it is done, so LS can release WS1’s locks

如果WS1在写入WAL前故障，则cache data会丢失，但是filesystem仍然具有一致性。

在crash recovery过程中，不能reply已经apply的log record， 不然会出现问题。Frangipani通过version number来解决该问题，metadata block都有对应的version number，每次metadata block更新时会记录version number，如果log version number <= metadata block versionnumber，说明该log已经apply。

Log record并没有保存user data，即具体的file content，会有什么后果：

• If no crash, this is hidden by locks, so it doesn’t matter
• If crash, Petal may be left with a random subset of recent writes，for many apps, this doesn’t matter

缺陷

Frangipani有如下缺陷：

• A file system is not a great API for many applications, e.g. web site
• Frangipani enforces permissions, so workstations must be trusted
• Frangipani/Petal split is a little awkward
  – both layers log
  – Petal may accept updates from “down” Frangipani workstations
  – more RPC messages than a simple file server