在具有障碍的SATA驱动器上写入caching的安全性

最近我一直在阅读有关SATA驱动器的写caching,NCQ,固件错误,障碍等问题,而且我不确定什么样的最佳设置可以让我的数据在发生电源故障的情况下安全。

据我所知,NCQ允许驱动器对写入进行重新sorting以优化性能,同时让内核知道哪些请求已经被物理写入。

写入caching使驱动器更快地提供请求,因为它不会等待将数据写入物理磁盘。

我不确定NCQ和写入caching如何在这里混合…

文件系统,特别是需要logging的文件系统,需要确定何时写下了一个特定的请求。 另外,用户空间进程使用fsync()强制刷新特定文件。 对fsync()的调用在文件系统确定数据写入磁盘之前不应该返回。

有一个function(FUA,强制单元访问),我只在SAS驱动器上看到过,它强制驱动器绕过caching并直接写入磁盘。 对于其他任何事情,都有写障碍,这是由内核提供的机制,可以触发驱动器上的caching刷新。 这迫使所有的caching被写下来,而不仅仅是关键数据,因此如果被滥用,则会减慢整个系统,例如使用fsync()。

那么存在固件缺陷的驱动器,或者故意在数据被物理写入时撒谎。

说了这个..有几种方法来设置驱动器/文件系统:A)NCQ和写caching禁用B)只是NCQ启用C)只写caching启用D)NCQ和写caching启用

我越来越障碍启用..顺便说一句,如何检查,如果他们实际上启用?

在断电的情况下,在积极写入磁盘的同时,我的猜测是选项B(NCQ,无caching)对于文件系统日志和数据都是安全的。 可能会有性能损失。

如果使用障碍或FUA,选项D(NCQ +高速caching)将对使用fsync()的文件系统日志和应用程序是安全的。 在caching中等待的数据是不好的,这取决于文件系统来检测它(校验),至less文件系统不会(希望)处于不稳定的状态。 在性能方面,应该会更好。

然而,我的问题是…我错过了什么? 还有其他的variables需要考虑吗? 有没有什么工具可以证实这一点,而我的驱动器的行为应该是他们应该的?

对于直线型的企业级系统,还有一个以存储适配器(通常是RAID卡)forms存在的另外一层存储层。 现在存储堆栈中有很多抽象概念,我在一个关于了解你的I / O的博客系列中深入细节。

RAID卡可以绕过磁盘caching,其中一些甚至允许在RAID BIOS中切换此function。 这是企业磁盘为Enterprise的原因之一,他们的固件允许消费者驱动器( 尤其是 “绿色”驱动器)不这样做。 此function直接解决您所关心的情况:未合并写入的电源故障。 应该是电池或闪存支持的RAID卡caching将保留,直到电源恢复,这些写入可以重新编译。

某些企业级固态硬盘包含一块板载电容,在完全closures电源前提供足够的性能提供板载高速caching。

如果您正在使用直接连接到主板的磁盘系统,那么保证的数量就会减less。 除非磁盘本身具有写入caching的能力,否则电源故障确实会造成损失。 由于xfs文件系统无法在这种失败模式下继续存在,因此获得了不可靠的声誉。 它旨在运行在具有工程存储生存能力的完整企业系统上。

然而,时间已经过去了,XFS已经被devise来生存下来。 其他主要的Linux文件系统(以及Windows上的ntfs )已经有了工程,可以在这种非常失败的模式下生存。 它应该如何工作的是,丢失的写作不会出现在FS杂志上,它会知道他们没有得到认同,所以腐败将被安全地检测和解决。

你在这里指出一个问题:谎言的磁盘固件。 在这种情况下,FS期刊将会对现实做出错误的假设,腐败可能在一段时间内不会被发现。 奇偶校验RAID和镜像RAID可以解决这个问题,因为应该有另一个comitted的副本来拉。 但单磁盘设置将不会有交叉检查,所以实际上是错误的。

通过使用获得更多validation的企业级驱动器(并与您假定的工作负载模式进行testing),devise存储系统以便能够承受这种虚假情况,从而避免固件风险。

假定没有驱动器写入caching,在发出写入元数据之前,文件系统日志最初等待写入日志完成。 随着驱动器写入caching启用,这个假设被打破,可能会导致数据丢失。 因此,创造了障碍。 有了障碍,日志可以确保在写入元数据之前写入日志完成,即使磁盘正在使用写入caching。 在磁盘驱动器层,当驱动器报告它有一个写入caching并且被启用时,在下一个IO发送closures之前,屏障强制磁盘caching刷新。 否则,这是不需要的,所以障碍只是防止发送后续IO到驱动器,直到前一个IO完成。 NCQ只是意味着它可能需要等待多个待处理的请求才能完成,然后再发出更多请求。