我熟悉 BBWC（电池供电写入缓存）的用途 - 以前在我的服务器中使用过它们，即使 UPS 很好。显然有些故障它无法提供保护。我很好奇它在实践中是否真的能带来任何实际好处。
（注意：我特别想了解拥有 BBWC 并经历过坠机/故障的人的回应，以及 BBWC 是否有助于恢复）
更新
在收到这里的反馈后，我越来越怀疑 BBWC 是否增加了任何价值。
要确保数据完整性，文件系统必须知道数据何时被提交到非易失性存储（不一定是磁盘 - 这一点我后面会谈到）。值得注意的是，很多磁盘在数据被提交到磁盘时撒谎（http://brad.livejournal.com/2116715.html)。虽然可以合理地假设禁用磁盘缓存可能会使磁盘更加诚实，但仍然不能保证情况确实如此。
由于 BBWC 中的缓冲区通常很大，屏障可能需要将更多数据提交到磁盘，从而导致写入延迟：一般建议在使用非易失性写回缓存时禁用屏障（并禁用磁盘缓存）。然而，这似乎会破坏写入操作的完整性——仅仅因为在非易失性存储中维护了更多数据并不意味着它会更加一致。事实上，可以说，如果没有逻辑事务之间的划分，确保一致性的机会似乎比其他情况更少。
如果 BBWC 在数据进入非易失性存储（而不是提交到磁盘）时确认屏障，那么它似乎可以满足数据完整性要求而不会影响性能 - 这意味着屏障仍然应该启用。但是，由于这些设备通常表现出与将数据刷新到物理设备一致的行为（使用屏障时速度明显变慢）以及禁用屏障的广泛建议，因此它们不能以这种方式表现。为什么不呢？
如果操作系统中的 I/O 被建模为一系列流，那么当操作系统管理写入缓存时，就有一定的空间来最小化写入屏障的阻塞效应 - 因为在这个级别上只需要提交逻辑事务（单个流）。另一方面，不知道哪些数据位构成事务的 BBWC 必须将其整个缓存提交到磁盘。内核/文件系统是否真正在实践中实现这一点将需要比我目前愿意投入的更多的努力。
磁盘对已提交的内容撒谎，再加上突然断电，无疑会导致损坏 - 并且对于在断电后不进行完整 fsck 的日志或日志结构文件系统，不太可能检测到损坏，更不用说尝试修复它了。
就故障模式而言，根据我的经验，大多数突然断电都是由于主电源断电而发生的（使用 UPS 和受控关机可以轻松缓解）。人们从机架中拔出错误的电缆意味着数据中心卫生状况不佳（标签和电缆管理）。有些类型的突然断电事件是 UPS 无法预防的 - PSU 或 VRM 发生故障，带有屏障的 BBWC 可在发生故障时提供数据完整性，但此类事件有多常见？从这里缺乏回应来看，非常罕见。
当然，将容错能力提升到堆栈中更高的位置比 BBWC 的成本要高得多 - 但是，将服务器实现为集群对于性能和可用性还有很多其他好处。
减轻突然断电影响的另一种方法是实施 SAN - AoE 使这成为一个实用的提议（我不太明白 iSCSI 的意义所在）但同样成本较高。
答案1
当然。我曾使用电池支持的缓存 (BBWC) 和后来的闪存支持的写入缓存 (FBWC) 来保护在发生崩溃和突然断电后的数据。
在 HP ProLiant 服务器上，典型的消息是：
POST Error: 1792-Drive Array Reports Valid Data Found in Array Accelerator
意思是，“嘿，写缓存中有一些在重启/断电后仍能保留的数据！我现在要将其写回到磁盘！“
一个有趣的案例是我对一个系统在龙卷风，数组顺序为：
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 错误是独一无二的。- 当系统正在使用时，电源中断，而数据位于阵列加速器内存中。然而，由于这是一场龙卷风，电力在四天内没有恢复，因此阵列电池电量耗尽并且其中的数据丢失。服务器有两个 RAID 控制器。另一个控制器有一个 FBWC 单元，其使用寿命比电池长得多。该驱动器恢复正常。由于电池电量耗尽，阵列上出现了一些数据损坏。
尽管设施内的电池运行时间充足，但四天的断电和危险的情况使得任何人都无法安全关闭服务器。
答案2
是的，有过这种情况。
数据中心内“无 UPS”的服务器（数据中心配有 UPS）。PDU 故障 - 系统严重崩溃。无数据丢失。
基本上就是这样。BBWC 的优点在于它位于机器中。配备 UPS - 相信我，有时有人会做一些愚蠢的事情（例如拉错电缆）。UPS 是外部的。哦，那根电缆 ;)
答案3
我曾经遇到过 2 次 HW RAID 控制器中的电池供电缓存完全失效的案例（分别在 2 家不同的公司）。
BBC 依赖电池工作这一不足为奇的想法。问题在于，控制器中的电池有时会失效，而令人震惊的是，许多 HW 突袭控制器中的电池都会失效默默。我们以为我们有一个可以防止断电的缓存，但事实并非如此。
断电后，RAID 阵列数据丢失严重，所有磁盘内容都无法恢复。一切都丢失了。其中一个案例涉及一台专门用于测试的机器，但仍然如此。
之后，我表示“再也不用了”，转而使用 Linux 中的基于软件的磁盘镜像 (mdadm) + 基于日志的文件系统，这种文件系统对断电 (ext4) 具有良好的恢复能力，并且再也没有回头。当然，我曾在 IO 使用率不是特别高的服务器上使用过它。
答案4
除了“保存数据”之外，它们还有其他用处。它们还擅长缓冲写入（在缓存中），从而通过保持磁盘写入队列较低来提高 IO 子系统的性能。这对于交互式性能至关重要的服务器（例如 Citrix XenApp 或 Windows Terminal Services）尤其重要。
对于网络服务器或文件服务器来说，这一点并不那么重要。您可能不会注意到，甚至不习惯一点延迟。但是，当您单击 Office 应用程序中的图标时，您会期望响应。您的 CEO 也是如此。