BBWC：理论上是一个好主意，但有一个曾经保存过你的数据？

我很熟悉BBWC（电池支持的写入caching）打算做什么 – 以前曾在我的服务器中使用它们，即使是使用良好的UPS。有不可预料的失败，它不提供保护。我很好奇它是否真的在实践中提供了实际的好处。

（注意，我特别寻找那些有BBWC的人的反应，并且有崩溃/失败，以及BBWC是否帮助恢复）

更新

经过这里的反馈，我越来越怀疑BBWC是否增加了任何价值。

为了对数据完整性有信心，文件系统必须知道数据何时被提交到非易失性存储器（不一定是磁盘 – 我将回到这一点）。值得注意的是，当数据被提交到磁盘时，大量的磁盘都是谎言（ http://brad.livejournal.com/2116715.html ）。虽然认为禁用磁盘caching可能会使磁盘更加诚实似乎是合理的，但仍然不能保证也是如此。

由于BBWC中的缓冲区很大，因此屏障可能需要将更多的数据提交到磁盘，从而导致写入延迟：一般的build议是在使用非易失性回写高速caching时禁用屏障（并禁用片上caching）磁盘caching）。然而，这似乎破坏了写入操作的完整性 – 仅仅因为在非易失性存储中维护更多的数据并不意味着它会更加一致。实际上，逻辑交易之间可以说没有划分，似乎没有机会确保一致性。

如果BBWC在数据input到非易失性存储（而不是承诺磁盘）的时候承认存在障碍，那么它似乎满足数据完整性要求，而不会有性能损失 – 这意味着应该仍然启用障碍。然而，由于这些设备通常performance出与将数据刷新到物理设备（显着慢于屏障）和广泛的禁用屏障的build议一致的行为，因此它们不能以这种方式performance。为什么不？

如果操作系统中的I / O被build模为一系列stream，那么当写caching由OSpipe理时，有一定范围可以最小化写屏障的阻塞效应 – 因为在此级别只有逻辑事务（单个stream）需要承诺。另一方面，不知道哪些数据位构成事务的BBWC将不得不将其整个caching提交到磁盘。在实践中，内核/文件系统是否真正实现了这一点，需要比我现在想要投资的更多的努力。

磁盘组合告诉fib什么已经承诺和突然失去权力无疑会导致腐败 – 和一个Journalling或日志结构的文件系统，在停电后不能完全fsck不太可能检测到腐败，更不用说了试图修复它。

就故障模式而言，根据我的经验，大多数突然断电都是由于主电源断电（容易通过UPS进行缓解以及pipe理关机）而发生的。人们把错误的电缆从机架中拉出来意味着数据中心的不良（标签和电缆pipe理）。有些types的突然掉电事件不会被UPS阻止 – 在PSU或VRM故障时，带有障碍的BBWC将在这里出现故障时提供数据完整性，但是这种事件有多普遍？在这里没有回应，这是非常罕见的。

当然，将堆栈中的容错移动到更高的位置是比BBWC更昂贵的 – 但是，将服务器作为群集来实现，对于性能和可用性还有很多其他好处。

另一种减轻突然断电影响的方法是实施一个SAN-AoE，使其成为一个实际的主张（我在iSCSI中并没有真正看到这一点），但是成本更高。

当然。我有电池支持caching（BBWC）和后来的闪存支持写入caching（FBWC）保护飞机上的数据，在崩溃和突然断电后。

在HP ProLiant服务器上，典型的消息是：

POST Error: 1792-Drive Array Reports Valid Data Found in Array Accelerator

这意味着， “ 嘿，写入caching中的数据在重新启动/断电的情况下幸存下来！我现在要把它写回磁盘！ ”

一个有趣的例子是我在龙卷风失去能量的系统的验尸后，arrays顺序是：

 POST Error: 1793-Drive Array - Array Accelerator Battery Depleted - Data Loss POST Error: 1779-Drive Array Controller Detects Replacement Drives POST Error: 1792-Drive Array Reports Valid Data Found in Array Accelerator

1793 POST错误是唯一的。 – 系统正在使用时，数据在arrays加速器内存中时电源中断。然而，由于这是一场龙卷风，电力在四天内没有恢复， arrays电池耗尽 ，内部数据丢失。服务器有两个RAID控制器。另一个控制器有一个FBWC单元，它比电池持续时间长得多。该驱动器恢复正常。一些数据损坏在由空电池支持的arrays上产生。

尽pipe在设施中有大量的电池运行时间，但是四天没有电力和危险的条件使任何人都无法安全地closures服务器。 在这里输入图像描述

是的，有这种情况。

服务器“没有UPS”在数据中心（数据中心有UPS）。 PDU失败 – 系统崩溃。没有数据丢失。

而这基本上是这样的。 BBWC的好处在于它在机器中。有一个UPS – 相信我，有时候会有人做一些愚蠢的事情（比如拉错电缆）。 UPS是外部的。哦，那个电缆;）

在HW RAID控制器的电池支持caching完全失败的情况下（在两家独立的公司）有两种情况。

BBC依靠电池工作的出人意料的想法。问题是，在某些时候，控制器中的电池出现故障，而且在很多硬件RAID控制器中，这种破坏是无声的 。我们认为我们有一个防止电力损失的caching，但我们没有。

在断电时，RAIDarrays数据丢失非常广泛，所有磁盘内容都无法恢复。一切都失去了。其中一个案例涉及一台完全用于testing的机器，但仍然如此。

之后，我说“再也不用”了，转而使用基于Linux +基于日志的文件系统中的基于软件的磁盘镜像（mdadm），它具有很好的恢复能力（ext4），永不回头。当然，我已经在没有非常高的IO使用率的服务器上使用它。

这似乎需要第二个问题的答案…

我刚刚有一个独立的VMware ESXi主机在RAID 5arrays中失去了一个驱动器。降级的arrays在VM和应用程序级上影响性能。

 Smart Array P410i in Slot 0 (Embedded) (sn: 5001438011138950) array A (SAS, Unused Space: 0 MB) logicaldrive 1 (1.6 TB, RAID 5, Recovering, 42% complete) physicaldrive 1I:1:1 (port 1I:box 1:bay 1, SAS, 300 GB, OK) physicaldrive 1I:1:2 (port 1I:box 1:bay 2, SAS, 300 GB, Rebuilding) physicaldrive 1I:1:3 (port 1I:box 1:bay 3, SAS, 300 GB, OK) physicaldrive 1I:1:4 (port 1I:box 1:bay 4, SAS, 300 GB, OK) physicaldrive 2I:1:5 (port 2I:box 1:bay 5, SAS, 300 GB, OK) physicaldrive 2I:1:6 (port 2I:box 1:bay 6, SAS, 300 GB, OK) physicaldrive 2I:1:7 (port 2I:box 1:bay 7, SAS, 300 GB, OK) physicaldrive 2I:1:8 (port 2I:box 1:bay 8, SAS, 300 GB, OK, spare)

该公司的IT人员并不知道驱动器发生故障，并且硬重置了服务器（ 为了让它更好？ ）。

这样做的一个有趣的影响，以一个妥协的arrays与繁忙的虚拟机运行在顶部是这样的：

caching状态详细信息：当前arrays控制器上次重置或上电时，在其电池/电容支持的写入caching中存储了有效数据。这表明系统可能没有被正常closures。 arrays控制器已经自动写入或试图将这些数据写入驱动器。该消息将继续显示，直到arrays控制器的下一个复位或重新启动。

所以即使系统突然中断，飞行中的数据也受到了BBWC的保护。虚拟机全部恢复正常，系统现在状态良好。

除了“保存你的数据”之外，它们还有其他的好处。他们还善于缓冲写入（在caching中），以便通过保持磁盘写入队列低来提高IO子系统的性能。这对于交互式性能至关重要的服务器尤其重要 – 例如，Citrix XenApp或Windowsterminal服务。

这对于Web服务器或文件服务器来说不太重要。你可能没有注意到，甚至习惯了一点点滞后。但是，当您单击Office应用程序中的图标时，您期望响应。你的首席执行官也是如此。