为什么已知有坏块的硬盘驱动器(在HDTune和HDDScan中经过验证)会冻结整个系统?

它不是OS驱动器;它已连接到另一个SATA端口,并且我正尝试将文件从其复制到另一个正常运行的驱动器。

几乎所有损坏的硬盘驱动器和每台Windows PC都遇到此问题。

我希望只会看到我用于复制文件的程序(Windows资源管理器等)冻结,但是我的整个PC都变得混乱,并且在复制文件时无法浏览网页或观看电影损坏的驱动器。

长话短说。

我生活在农村地区,那里有电问题(电力不足等)。我自己使用的是UPS,我自己的硬盘也很好。但是我的邻居经常在PC问题上寻求帮助,而且我经常发现他们的硬盘损坏,很可能是因为电力问题。当然,更换损坏的驱动器后,我建议邻居们购买一台UPS。

我一直想知道为什么我的PC在从损坏的驱动器中检索数据时会完全死机。这是硬件问题吗?这是由OS读取数据的方式引起的吗?这是Windows特定的东西,我不会在* nix上体验吗?

无论如何,从现在开始,我将使用一些专用软件(例如Roadkil的Unstoppable Copier)代替Windows Explorer。我不确定在不冻结整个PC的情况下是否会以其他方式工作。

这不是寻求帮助,更多是出于教育目的,所以我知道事情为何如此运行。 br />

评论

使用外部USB机箱应该会有所帮助,因为您不再需要将故障磁盘与系统SATA控制器绑定在一起(而且,在主板和故障磁盘之间添加额外的可牺牲硬件层总是一个好主意)。

它不特定于SATA,IDE驱动器也可以做到这一点。同样,仅仅因为磁盘损坏并不意味着控制器就不存在,尤其是在电气故障损坏磁盘的情况下。

接受的答案很棒,它包含了我要说的内容以及更多其他内容。基本上,您正在惊慌您的SATA控制器,这是一个非常重要的系统设备,继而会导致Windows崩溃。我确实想知道是否在BIOS中启用AHCI /“ hot-swap”是否可以改善这种情况。

#1 楼

这是SATA次优的领域之一。问题出在存储设备互连协议级别,因此与您正在运行的软件无关。使用另一台文件复印机或另一台操作系统不会神奇地使事情变得更好,只是它可能会尝试设置不同的超时值以减少问题的影响(这可能会或可能不会,具体取决于硬件和固件;请参见下文)。 )。

这里有一些重要要点:


使用SATA,如果驱动器停止响应,则可以占用整个存储系统,而不仅仅是一个有问题的驱动器。当然,它有可能捆绑整个控制器,并且由于大多数消费者系统只有一个磁盘控制器(集成在主板上的一个磁盘控制器),因此意味着所有存储空间。如果驱动器以某种非标准和/或意外的方式发生故障,则更糟,如果驱动器处于临界状态,则肯定会发生这种情况。您可能对以下问题感兴趣:硬件SATA RAID-10阵列中的单个磁盘如何使整个阵列停止运转?服务器故障。
大多数消费者SATA驱动器具有较长的默认超时时间(以分钟为单位),并且许多消费者SATA驱动器缺乏可配置的错误恢复控制。所谓的“ NAS”驱动器通常具有可配置的ERC,而高端驱动器实际上总是如此。此类驱动器的默认超时时间也可能较短(常见值为7秒)。如果驱动器仅保留数据副本,则较长的超时时间是有利的,这在用户系统上很常见;它们在冗余配置中是不利的,或者您只是想在驱动器进一步恶化之前尽可能多地离开驱动器。
驱动器将继续尝试读取坏扇区,直到达到超时阈值或主机发出中止信号为止。由于可以通过等待读取完成来捆绑SATA总线,因此操作系统可能无法发出存储级命令中止的信号,并且在极端情况下,驱动器甚至可能无法很好地响应SATA总线复位在这种情况下。

点1是服务器上SAS的主要卖点之一; SAS具有比SATA更好的错误处理能力。第2点是驱动器固件的局限性,第3点实际上仅是由于#2才成为问题。

所以发生的是,操作系统向磁盘发出了“读取扇区”命令,并且某些部门受到某种程度的破坏。因此,磁盘进入重试模式以尝试从磁盘中取出数据,一次又一次地尝试读取,直到获得足够的数据以使磁盘自身的纠错(FEC)能够纠正剩余的错误。如果您不走运,可能永远都不会,但是驱动器将继续尝试相当长的时间,然后再决定读取操作不会成功。

因为操作系统正在等待读取后,这至少会减慢复制到爬网的速度,并且取决于确切的OS体系结构,可能会导致OS在整个过程中变得生涩甚至冻结。此时,磁盘正忙于原始读取,直到当前正在执行的磁盘结束(成功或不成功),其他任何软件通常都不会比其操作系统更好地响应原始读取正在运行。

因此,任何触发在其他地方(理想情况下,仅在损坏的驱动器上)进行读取的操作都必须排队等待,直到损坏的驱动器成功读取有问题的扇区或确定无法读取该扇区为止。由于SATA不能很好地处理无响应驱动器,这可能意味着不仅要复制的驱动器的I / O都会延迟。这很容易导致其他软件变慢或无响应,因为该软件会等待其他I / O请求完成,即使操作系统能够应对。

这也很重要需要注意的是,即使您没有显式访问磁盘上的任何文件,也可能发生磁盘I / O。造成这种情况的两个主要原因是按需加载可执行代码和交换。由于有时即使在系统没有内存压力的情况下也使用交换功能,并且按需加载的可执行代码在现代系统和现代可执行文件格式中很常见,因此在正常使用期间发生意外的磁盘读取活动是非常现实的可能性。 />
正如Matteo Italia在对问题的评论中指出的那样,一种缓解策略是使用不同的存储互连,这是一种“将磁盘放入USB机箱”的复杂方式。通过抽象化USB大容量存储协议,可以将有问题的SATA部分与系统的其余部分隔离开,这意味着从理论上讲,该磁盘上的I / O问题仅会影响该特定磁盘上的I / O。

顺便说一句,这就是为什么通常不建议将SATA(特别是没有驱动器级ERC的SATA)用于RAID(尤其是具有冗余的RAID级别,在标准级别中除RAID 0以外的所有RAID))。较长的超时时间和差的错误处理能力很容易导致整个设备因单个坏扇区而被扔出阵列,如果存在冗余并且存储控制器完全知道这就是问题,那么RAID控制器就可以很好地处理它。 SAS是为大型存储阵列而设计的,因此期望在各种驱动器上偶尔会出现问题,这导致它被设计为可以优雅地处理单个有问题的驱动器或I / O请求的情况,即使驱动器没有t。有问题的磁盘在用户系统中不是很常见,原因仅在于这些磁盘往往没有安装太多磁盘,而已安装的磁盘实际上从来没有冗余。由于SATA旨在取代PATA / IDE而不是SCSI(后者是针对SAS的小众市场),因此它的错误处理功能和要求(或保证)可能被认为足以满足其预期的使用情况。

评论


感谢您实际发布一个明智的答案,以解释发生了什么。在这种问题中,我通常会看到一些模糊的答案,例如“因为系统正在等待驱动器”或“因为它是按照这种方式设计的”。

–user541686
2015年8月10日在2:59

@kasperd:差不多。尽管它的一部分也是Windows的“故障”,但使用多个控制器也很容易发生。 IMO认为这个答案有点含糊,因为企业SAS控制器也不能幸免。它实际上只是归结为某些阻塞的I / O请求。一些硬盘驱动器操作要求确保操作X必须在操作Y之前完成,并且如果X从未完成,则Y将永远不会开始-并且在Y卡住之后的任何事情,无论驱动器,控制器,驱动器或操作系统是否处于运行状态,故障。

– qasdfdsaq
15年8月10日在10:44

@JustAMartin实际上,几乎所有异步-现在支持DMA的任何外设都充满了异步;内核仅调度请求并处理表明请求已完成的中断。问题是,有时您必须等待操作完成-并且在此过程中,它们可能会阻塞重要的事情。正如user20574所指出的,虚拟内存就是其中之一,但是很多事情需要一些保证。内核的某些部分不是异步的,当然,某些驱动程序/设备只是很烂。

–罗安
15年8月11日在9:04

@MichaelKjörling“由于操作系统正在等待读取,这至少会减慢复制到爬网的速度,并且取决于确切的OS体系结构,可能会导致OS在整个过程中变得生涩甚至冻结。” -从辅助(非系统)驱动器读取数据时,为什么OS会变得混乱?问题不能完全归因于SATA控制器的错误处理行为。我认为该答案可能会受益于Windows如何处理其磁盘子系统中的错误的信息。

–乔丹·里格(Jordan Rieger)
2015年8月11日在20:51



@MichaelKjörling足够公平。答案有很多不错的信息,但是我认为这并不能完全解释OP的特定情况。要换一个角度来看,您是否可以引用任何参考文献来备份您的观点#1:“使用SATA,如果驱动器停止响应,这可能会占用整个存储系统,而不仅仅是一个有问题的驱动器当然,它有可能束缚整个控制器。”这似乎是一个糟糕的设计。难道不是OS磁盘子系统是元凶?即控制器是异步的,但是OS驱动程序有时会不必要地阻塞。

–乔丹·里格(Jordan Rieger)
15年8月11日在21:11

#2 楼

如上所述,由于硬盘驱动器损坏而导致系统死机的问题主要是由于驱动器长时间尝试从坏扇区中恢复无法读取的数据。企业驱动器的卖点之一是故障扇区的读取超时非常短。使用企业级驱动器可以在一定程度上缓解您的问题,但不能解决问题。

最好的答案是继续维护正确的备份,这样就不需要恢复。更改恢复软件不会有任何变化,因为这是固件超时问题。

#3 楼


为什么损坏的硬盘驱动器会冻结整个系统?


它们通常不需要。实际上,这取决于特定的文件系统如何处理磁盘故障。

考虑ZFS,它是从头开始设计的,可以处理一定的容错能力。这是一个演示视频(还有更多说明),他们将正在运行的驱动器放在砧上,用大锤进行摆动,然后钻另一个驱动器。 ZFS一直在运行。

评论


实际上,ZFS无法很好地解决磁盘故障。例如,在冗余或非冗余设置中,在I / O请求超时之前的读取时间非常长。 (您可以以没有冗余的方式轻松设置ZFS。)这很容易导致驱动器从ZFS的阵列中抛出,如果这使您跌落到冗余阈值以下,则可能导致整个阵列失效。变得不可用。如果使用failmode = wait设置,则可以显示类似的结果。对于任何存储子系统,全盘全盘故障都是最容易发生的情况。是边缘驱动器引起了问题。

–用户
15年8月11日在21:04

而且,在您另行考虑之前,我实际上是自己运行ZFS(几乎全部)。如果您小心一点并知道自己在做什么,那么它是一个很棒的文件系统和一个很棒的卷管理器。但是,它是为企业级系统(高端工作站和服务器)设计的,管理员需要付费才能知道他们在做什么。它不能很好地处理商用硬件中出现的某些故障模式,包括RAM问题和从I / O请求返回所需的时间过长的驱动器,并且其设计不便于家庭用户或在家庭中使用。家庭用户用例。

–用户
2015年8月11日在21:08



除视频中外,ZFS不会继续运行。断开驱动器连接后,它将再次开始运行。

– ChristopherHammarström
15年8月13日在10:37

#4 楼

我认为您遇到的问题是操作系统的低级部分,在放弃之前,它会尝试多次读取坏块。如果在引导或其他独立操作期间需要此例程,则该例程在较低级别上实现,因此很难使其重入。操作系统将在正常操作期间连续进行页面调度,并且很难为竞争请求赋予优先级,因为低级系统将不知道拥有页面调度请求的进程的优先级。

评论


“低级系统”确实知道请求页面的进程的优先级。这些信息保存在页表中,尽管实现方式取决于系统如何处理优先级。但是,这不是该问题的正确答案-这是硬件问题,而不是操作系统问题。

–克里斯·西里菲斯(Chris Cirefice)
15年8月10日在15:41

我认为问题的正确答案是拒绝使用错误的驱动器。但是,这不能满足那些希望恢复尽可能多的数据的用户的需求。

– jrrk
15年8月10日在16:13