4.8 KiB
11.2 Frangipani的挑战（Challenges）
Frangipani的挑战主要来自于两方面，一个是缓存，另一个是这种去中心化的架构带来的大量的逻辑存在于客户端之中进而引起的问题。
.png)
第一个挑战是，假设工作站W1创建了一个文件 /A。最初，这个文件只会在本地缓存中创建。首先，Frangipani需要从Petal获得 / 目录下的内容，之后当创建文件时，工作站只是修改缓存的拷贝，并不会将修改立即返回给Petal。
.png)
这里有个直接的问题，假设工作站W2上的用户想要获取 / 目录下的文件列表，我们希望这个用户可以看到新创建的文件。这是一个用户期望的行为，否则用户会感到非常困惑。比如我在大厅里喊了一嘴说我把所有有意思的信息都放到了这个新创建的文件_/A_中，你们快去看一看啊。但是当你从W2上尝试读取这个文件，却找不相应的文件。所以这里我们想要非常强的一致性，这样当有人在大厅里说自己在文件系统里面做了修改，其他人应该能看到这个修改。另一个场景是，如果我在一个工作站修改了文件，之后在另一个计算机上编译它，我期望编译器能看到我刚刚做的修改。这意味着，文件系统必须要做一些事情来确保客户端可以读到最新的写入文件。我们之前讨论过这个话题，我们称之为强一致或者线性一致，在这里我们也想要这种特性。但是在一个缓存的环境中，现在说的一致性的问题不是指存储服务器的一致性，而是指工作站上的一些修改需要被其他工作站看到。因为历史的原因，这通常被称为缓存一致性（Cache Coherence）。这是缓存系统的一个属性。它表明，如果我缓存了一个数据，并且其他人在他的缓存中修改了这个数据，那么我的缓存需要自动的应用那个修改。所以我们想要有这种缓存一致性的属性。
另一个问题是，因为所有的文件和目录都是共享的，非常容易会有两个工作站在同一个时间修改同一个目录。假设用户U1在他的工作站W1上想要创建文件_/A_，这是一个在 / 目录下的新文件，同时，用户U2在他的工作站W2上想要创建文件 /B 。
.png)
这里他们在同一个目录下创建了不同名字的两个文件A和B，但是他们都需要修改根目录，为根目录增加一个新的文件名。所以这里的问题是，当他们同时操作时，系统能识别这些修改了相同目录的操作，并得到一些有意义的结果吗？这里的有意义的结果是指，A和B最后都要创建成功，我们不想只创建一个文件，因为第二个文件的创建有可能会覆盖并取代第一个文件。这里期望的行为有很多种叫法，但是这里我们称之为原子性（Atomicity）。我们希望类似于创建文件，删除文件这样的操作表现的就像即时生效的一样，同时不会与相同时间其他工作站的操作相互干扰。每一个操作就像在一个时间点发生，而不是一个时间段发生。即使对于复杂的操作，涉及到修改很多状态，我们也希望这些操作表现的好像就是即时生效的。
最后一个问题是，假设我的工作站修改了大量的内容，由于Write-Back缓存，可能会在本地的缓存中堆积了大量的修改。如果我的工作站崩溃了，但是这时这些修改只有部分同步到了Petal，还有部分仍然只存在于本地。同时，其他的工作站还在使用文件系统。那么，我的工作站在执行操作的过程中的崩溃，最好不要损坏其他人同样会使用的文件系统。这意味着，我们需要的是单个服务器的故障恢复，我希望我的工作站的崩溃不会影响其他使用同一个共享系统的工作站。哪怕说这些工作站正在查看我的目录，我的文件，它们应该看到一些合理的现象。它们可以漏掉我最后几个操作，但是它们应该看到一个一致的文件系统，而不是一个损坏了的文件系统数据。所以这里我们希望有故障恢复。一如既往的，在分布式系统中，这增加了更多的复杂度，我们可以很容易陷入到这样一个场景，一个工作站崩溃了，但是其他的工作站还在运行。
.png)
对于所有的这些内容，所有的3个挑战，在我们接下来的讨论中，我们会关注Frangipani是如何应对这些挑战。对于Petal虚拟磁盘，它也会有许多类似的关联问题，但是它不是今天关注的重点。Petal有完全不同的，可靠的容错机制。实际上，它与我们之前讨论过的Chain-Replication非常相似。