HDD用零覆盖的速度更快吗?


52

我有一台装有两个操作系统的PC,使用从UbuntuUSB的磁盘擦除了该硬盘。我选择了快速擦除。据我了解,它删除了分区表,但是所有文件的一和零仍然在硬盘上。然后,我创建了新的分区表,并安装了Win10。

问题:如果我用零覆盖硬盘,那么现在硬盘(读/写)的工作速度会更快吗?
或者:将信息写入零覆盖的硬盘的速度是否比“脏”硬盘快?


1
在这方面可能值得一提的是ATA Secure擦除。这可能不直接用于OP,但可能对其他人有用。
StephenG

您是否在询问(磁性)HDD,SSD或两者?答案取决于。
smci

值得一提的是,如果先清除为默认值,可以在微控制器封装中找到的物理寻址闪存更快,因为您可以从头开始进行此操作。
MooseBoys

Answers:


92

硬盘不存储字面零和我怀疑您​​认为的零。相反,它们以编码格式存储数据,以确保彼此之间不会有太多零位或一位。长期零或实际上可能会在尝试读取数据时引起同步问题,这是因为数据在其上编码的物理介质的盘片速度,振动等的微小变化,因此将其限制为一定的公差。

此外,硬盘驱动器始终总是一次编码整个扇区(通常为512字节或4096字节的数据),而不仅仅是已更改的位(再次,因为它是对数据进行编码)。这确保了每次都正确编码整个扇区。因此,用全零填充驱动器没有任何实际好处,尽管它也不会造成任何损害,除了这样做会造成轻微的机械磨损。如果愿意,您可以选择用零覆盖所有内容,但这不会带来性能上的好处,并且您只会浪费时间等待所有这些零被写入。

固态驱动器也要经历类似的过程。它们会在写入新的数据块之前自动擦除该块的先前内容,因此将全零写入SSD会导致设备不必要的磨损,因为闪存技术只能擦除一个变量,但是擦除次数有限,因此会失败。引入的磨损仅占总占空比的0.01%,但是您要避免定期进行磨损。


9
can only be erased a certain number of times—实际上,数量不确定。差异很大
Ruslan '18

19
我猜@Ruslan可怜的单词选择。不确定(只有死亡和税收才是确定的),但这绝对是有限的,制造商仅保证性能达到“占空比”的次数。
phyrfox

在具有内部压缩但不支持TRIM的旧SSD上,写入零可能会使闪存重映射层使用较少的物理闪存空间来存储通过SATA接口公开的逻辑数据数组……这是一个扩展,并且比SATA安全性差。虽然擦除。
彼得·科德斯

5
您的答案有两个问题;1)Solid state drives go through a similar process。这是不正确的。硬盘驱动器不像SSD那样经历读/擦除/写周期。他们可以即时覆盖扇区,而不必先擦除它们。2)A long run of 0s or 1s could actually cause sync issues when trying to read the data也不正确。硬盘驱动器扇区在记录扇区号,同步位和ECC数据的扇区之间有间隙。地址和同步数据可防止磁头在盘上丢失。因此,4k扇区的长度实际上为4211字节。
Wes Sayeed

2
@WesSayeed“类似的过程”意味着SSD也可以一次写入整个扇区。没错,普通的硬盘驱动器不会首先擦除,但这仍然是一个类似的过程。两者都一次写入整个扇区。是的,我知道包含ECC和其他内容的扇区间间隙,但是他们仍然使用诸如MMFM / GCR之类的方法来确保时钟不会在该扇区内失同步,这意味着它们不能连续太多零位。
phyrfox

53

不,不会更快。不管要覆盖的数据如何,写入都花费相同的时间。


12
对于磁高清,这是正确的,但是TRIM如果使用零覆盖,则使用内部压缩而不支持的SSD 可能更快。他们将减少闪存上的实际空间,从而为闪存重新映射层留出更多的处理空间。所以这有点像TRIM /丢弃。
彼得·科德斯

2
@PeterCordes-的确如此,今天实际使用的SSD中有多少支持TRIM?我知道在我从多个产品世代和各种制造商(从高端一直到无品牌/商店品牌)使用的几种类型中,我遇到的所有类型都可以。
Jules

1
@PeterCordes的问题是关于零覆盖,而不是用于覆盖。内部压缩似乎没有成功,因为它只能以扇区粒度完成,并且可能难以跟上吞吐量。如果SSD没有配置空间,并且制造商将逻辑零映射到物理零,则写入零的速度可能会更快,因此,充满零的磁盘实际上是由“空”闪存页组成的。
玛格丽特·布鲁姆

@Jules:某些旧的SSD不支持TRIM,因为TRIM仅在第一个SSD存在后才被添加到ATA标准中,然后控制器需要花费一些时间来开始支持它。我有一台旧笔记本电脑。(我认为可以使用它的固件更新来添加TRIM支持)。我不确定那些没有TRIM的旧SSD是否也使用内部压缩。我应该说,如今这些SSD很少见,但是像这样的答案这样的笼统声明总是激励着我寻找不适合使用它们的反例或特殊情况。
彼得·科德斯

3
@Jules很大一部分的SSD不支持TRIM,主要是USB记忆棒,SD卡或MMC等较简单的闪存。几乎所有不是ATA的东西。
森林

10

这取决于:

  • 无论是机械硬盘还是固态硬盘。

如其他答案所述,对于SSD,您不应使用零覆盖(这将对Flash单元造成不必要的磨损),而应使用安全擦除或全盘TRIM。如果某些较新版本的格式化实用程序检测到SSD,则会自动执行TRIM。这样做的原因是,SSD在“空”扇区和一个“充满”任何数据(包括零)的扇区之间进行了强烈区分。

  • 驱动器上是否有不可读的扇区。

如果多年使用,许多驱动器将产生少量的“坏点”。任何已经遇到的问题都将在SMART数据中显示为“ Pending Uncorrectable”。

如果没有无法读取的扇区,则机械HDD 不会从覆盖中受益,尽管它除了会消耗大量的前期时间外,也不会造成任何危害。

如果一些无法读取的扇区,试图读取它们需要很长的时间,并且驱动将继续努力,以恢复在闲暇时刻,这将影响性能数据。覆盖它们将提示HDD丢弃现有数据,测试物理位置是否仍可用于存储,否则分配备用扇区。这还将重置“待处理的不可纠正”计数器。

TL; DR-通常不要这样做。


1
同样值得注意的是,用零覆盖可能是闪存最糟糕的事情:写入闪存块的过程是先将其擦除(将位设置为1),然后再写入需要擦除的位。为0。我不确定,但是我认为,如果将一个扇区全部写为零,则对设备寿命的损害比写入随机模式要大,而对随机模式的写入要比对所有1造成的损害更大,因为如果0少(此后不确定),随后的擦除操作将需要较少的功率,因此造成的损坏也较小(??)。
Jules

1
我认为大多数现代固态硬盘都可以减轻这种影响,例如反转标志,干扰模式甚至是温和的压缩方案。例如,由于将零转换为伪随机哈希,因此使用实时加密的驱动器实际上具有干扰模式。我仍然有一个旧的基于SandForce的驱动器,它使用压缩和重复数据删除来代替。但是您是正确的,较简单的闪存设备(拇指驱动器和SD卡)可能比实际数据快零磨损。
Chromatix

由于空间过大,以这种方式覆盖闪存驱动器也没有用。
森林

无需过多使用SSD。德语链接:heise.de/-3755009
user3549596 '18

5

不,用零覆盖将不会改变硬盘的速度。但是,对于固态驱动器,用零覆盖要比执行修整操作(将块标记为未使用)更糟糕。在安装操作系统之前,对SSD的分区或整个驱动器进行修整可能会提高SSD的性能和使用寿命。如果您已经安装了操作系统,则可以使用一些技术来修剪文件系统中的可用空间,从而获得类似的好处。


2

当您执行“慢速格式化”时,通常还会对驱动器上的坏块进行表面测试,因此对于较旧的HDD可能是合理的,但是您应该不会注意到任何R / W性能差异。


0

HDD或SDD都没有区别。

对于HDD,驱动器上的日期在您写入的每个扇区上都会发生磁性变化,因此与您在其中写入的内容无关。

此外,写入随机数据比写入零更好,因为它会使磁对准迹线更加混乱,并且对于高级取证而言,在随机数据覆盖与零覆盖的情况下,确定以前存在的内容将变得更加困难。

对于固态硬盘,如果您命令将值设为零或一没有区别,则仍然需要花费相同的时间来写入内存块,但是由于TRIM优化,您可能会发现无法覆盖特定区域你渴望。相反,只需制作一个占用所有可用空间的自扩展文件,这样就可以确保将所有内容都写入其中,从而防止任何恢复。


0

不,不会有任何速度差异,但是会造成不必要的磨损和不必要的故障机会。

传统的硬盘使用简单的伪随机生成器对数据进行编码,而更现代的硬盘则(几乎)所有SSD始终使用AES编码数据。这样做的原因是,无论是在磁驱动器上还是固态驱动器上,存储随机数据(或具有随机外观的数​​据)都对磨损均衡更有利,但特别是在后者的情况下(因此,首先使用AES来争夺比特币,但作为免费赠品,您可以免费获得安全性)。

因此,写出很多零将有效地写出很多“种类随机位”。

就是这样,并且读取(或覆盖)一个或另一个都不以任何方式更快。

另一方面,覆盖整个驱动器意味着要写入数十亿个扇区。尽管硬盘驱动器的故障率很低(完全是虚构的),以至于看起来像“从未发生”,但鉴于现代磁盘的巨大容量,“从未发生”更像是“很可能会发生”。出于这个原因,例如,不再推荐使用RAID-5,因为在发生故障的磁盘后尝试重新同步时遇到不可恢复的故障的可能性很高,以至于可能成为现实。

这意味着什么?好吧,这通常没有任何意义,但是不需要覆盖整个磁盘可能不是一个好主意。即使是安全擦除,如果有意的话,如今也存在更好(更快,更可靠)的方法。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.