5
BBWC：从理论上讲，这是个好主意，但是有没有人保存过您的数据？
我熟悉BBWC（电池支持的写缓存）的用途-甚至在使用优质UPS的情况下，它们也曾在我的服务器中使用过。显然存在无法提供保护的故障。我很好奇它在实践中是否真正提供了任何真正的好处。 （注意，我特别在寻找患有BBWC且发生车祸/故障以及BBWC是否有助于恢复的人的答复） 更新资料 收到反馈后，我越来越怀疑BBWC是否会带来任何价值。 为了对数据完整性有信心，文件系统必须知道何时将数据提交到非易失性存储（不一定是磁盘，这是我将要谈到的问题）。值得注意的是，将数据提交到磁盘后，会出现许多磁盘（http://brad.livejournal.com/2116715.html）。尽管可以合理地认为禁用磁盘上的缓存可能会使磁盘更老实，但仍然不能保证确实如此。 由于BBWC中的缓冲区通常过大，因此屏障可能需要将更多数据提交到磁盘，从而导致写入延迟：一般建议是在使用非易失性回写高速缓存时禁用屏障（并禁用on-磁盘缓存）。但是，这似乎破坏了写操作的完整性-仅因为非易失性存储中保留了更多数据并不意味着它会更加一致。确实，可以说在逻辑事务之间不进行划分，与其他方式相比，确保一致性的机会似乎更少。 如果BBWC在数据进入其非易失性存储（而不是提交到磁盘）的那一刻承认障碍，那么它似乎可以满足数据完整性要求而不会降低性能-意味着仍应启用障碍。但是，由于这些设备通常表现出与将数据刷新到物理设备一致的行为（带有障碍的速度明显较慢）以及禁用障碍的广泛建议，因此它们无法以此方式运行。为什么不？ 如果将OS中的I / O建模为一系列流，则在某种程度上可以最大程度地减小由OS管理写缓存时的写屏障的阻塞效果-因为在此级别仅逻辑事务（单个流） ）需要承诺。另一方面，一个不知道构成事务的数据位的BBWC必须将其整个缓存提交到磁盘。内核/文件系统是否实际上在实践中实现了这一点，将比我目前打算投入的工作多得多。 磁盘组合会告诉故障发生了什么，并且突然断电无疑会导致损坏-以及日记或日志结构化的文件系统在中断后无法完全执行fsck的情况下，更不可能发现损坏的发生，更不用说试图修复它。 就故障模式而言，根据我的经验，大多数突发性停电是由于市电中断而造成的（通过UPS和管理性关机可以轻松缓解）。人们将错误的电缆从机架中拔出，意味着数据中心的卫生性很差（标签和电缆管理）。UPS不能阻止某些类型的突然断电事件-PSU或VRM中的故障，带有障碍物的BBWC在发生故障时将提供数据完整性，但是这种事件有多普遍？从这里缺乏回应来看非常罕见。 当然，将容错能力提高到更高的堆栈中比使用BBWC的成本要高得多-但是将服务器实现为群集对于性能和可用性还有很多其他好处。 减轻突然断电的影响的另一种方法是实施SAN-AoE使这成为一个可行的方案（我对iSCSI的意义不大），但同样存在更高的成本。