问：introduction中说，在物理服务器上确保确定性的执行比在虚拟机上更难。为什么会出现这种情况？
答：在虚拟机上确保确定性比较容易，因为管理程序模拟和控制了硬件的许多方面，这些方面可能在主执行和备份执行之间有所不同，例如，中断交付的精确时间。
问：什么是hypervisor管理程序？
答：hypervisor管理程序是虚拟机系统的一部分；它与虚拟机监视器（VMM）相同。管理程序模拟一台计算机，客户操作系统（和应用程序）在模拟的计算机内执行。访客运行的模拟系统通常被称为虚拟机。在本文中，主用和备用都是在虚拟机内运行的客体，而FT是实现每个虚拟机的管理程序的一部分。
问：GFS和VMware FT都提供容错功能。我们应该如何选择哪一个更好？
答: FT复制计算；你可以用它来为任何现有的网络服务器透明地增加容错。FT提供相当严格的一致性，对服务器和客户是透明的。例如，你可以用FT来使现有的邮件服务器具有容错性。与此相反，GFS只为存储提供容错。因为GFS是专门针对特定的简单服务（存储），它的复制比FT更有效。例如，GFS不需要在所有副本上以完全相同的指令导致中断发生。GFS通常只是实现完整的容错服务的较大系统中的一个部分。例如，VMware FT本身依赖于主备共享的容错存储服务（图1中的共享磁盘），你可以使用类似GFS的东西来实现（尽管在详细的层面上，GFS并不完全适合FT）。
问：第3.4节的回弹缓冲区如何帮助避免竞争？
答：当一个网络数据包或请求的磁盘块到达主服务器并需要复制到主服务器的内存时，问题就出现了。在没有FT的情况下，相关硬件在软件执行时将数据复制到内存中。访客指令可以在DMA期间读取该内存；根据确切的时间，访客可能看到或看不到DMA的数据（这就是竞争）。如果主程序和备份程序都这样做，但由于轻微的时间差异，一个在DMA之后读取，另一个在DMA之前读取，那就不好了。在这种情况下，它们会出现分歧。FT避免了这个问题，因为当主存或备份正在执行时，不会复制到客存。FT首先将网络数据包或磁盘块复制到主程序无法访问的私有"回弹缓冲区"。当第一次拷贝完成后，FT管理程序会中断主程序，使其不在执行中。FT记录了它中断主程序的时间点（与任何中断一样）。然后，FT将回弹缓冲区复制到主程序的内存中，之后允许主程序继续执行。FT将数据发送到日志通道上的备份。备份的FT在主程序被中断的同一指令下中断备份，在备份进入执行状态时将数据复制到备份的内存中，然后再恢复备份。其效果是，网络数据包或磁盘块在主程序和备份程序中出现的时间完全相同，因此，无论它们何时读取内存，都会看到相同的数据。
问：什么是 "共享存储上的原子test-and-set操作"？
答：系统使用一个网络磁盘服务器，由主备双方共享 (图1中的 "共享磁盘")。该网络磁盘服务器有一个 "test-and-set服务"。test-and-set服务维护一个标志，该标志最初被设置为False。如果主服务器或备份服务器认为另一台服务器已经死亡，因此它应该自己接管，那么它首先向磁盘服务器发送一个test-and-set的操作。该服务器执行的大概是这样的代码:
代码语言：javascript复制test-and-set() {
acquire_lock()
if flag == true:
release_lock()
return false
else:
flag = true
release_lock()
return true
主服务器（或备份服务器）只有在test-and-set返回true时才会接管（"上线"）。更高层次的观点是，如果主站和备份站彼此失去网络联系，我们希望只有其中一个上线。危险的是，如果两者都在运行，而网络发生了故障，两者都可能上线，并形成脑裂。如果主服务器或备份服务器中只有一个能与磁盘服务器对话，那么这个服务器将单独上线。但是，如果两个都能与磁盘服务器对话呢？那么网络磁盘服务器就充当了破坏者的角色；test-and-set只对第一个调用返回true。
问：遵循Output Rule会损失多少性能？
答：表2提供了一些洞察力。遵循Output Rule，传输率会降低，但不是很高。
问：如果应用程序调用一个随机数生成器呢？这不会在主用和备用上产生不同的结果并导致执行的分歧吗？
答：主用和备用将从它们的随机数生成器得到相同的数字。所有的随机性来源都是由管理程序控制的。例如，应用程序可以使用当前时间，或硬件周期计数器，或精确的中断时间作为随机性的来源。在所有这三种情况下，管理程序都会拦截主用和备用的相关指令，并确保它们产生相同的值。
问：创造者如何确定他们捕获了所有可能的非决定性形式？
答：我的猜测是这样的。作者在一家公司工作，那里有很多人很了解虚拟机管理程序、微处理器和客体操作系统的内部结构，他们会意识到许多陷阱。具体到VM-FT，作者利用了以前一个项目（确定性重放）的日志和重放支持，这肯定已经处理了非确定性的来源。我猜测确定性重放的设计者做了大量的测试，并在VM-FT的作者使用的非确定性来源方面获得了经验。
问：如果主程序刚刚向外部世界发送输出后出现故障，会发生什么？
答：备份可能会在接管后重复输出，这样就会产生两次输出。这种重复对网络和磁盘I/O来说不是问题。如果输出是一个网络数据包，那么接收客户端的TCP软件会自动丢弃重复的数据。如果输出事件是一个磁盘I/O，那么磁盘I/O是同位的（都是把相同的数据写到同一个位置，而且没有中间的I/O）。
问：第3.4节谈到了当故障发生时主服务器上未完成的磁盘I/O；原文说："相反，我们在备份虚拟机的上线过程中重新发出待定I/O"。挂起的I/O位于/存储在哪里，重新发布需要追溯到多远？
答：本文讨论的是磁盘I/O，其中有一个日志条目表明I/O已经开始，但没有条目表明完成。这些是必须在备份上重新启动的I/O操作。当一个I/O完成时，I/O设备会产生一个I/O完成中断。因此，如果日志中缺少I/O完成中断，那么备份就会重新启动I/O。如果日志中存在I/O完成中断，那么就不需要重新启动I/O。
