硬盘写到一半时断电,文件系统里会发生什么?

 

断电时文件系统发生了什么?硬盘又发生了什么?下一次开机时写到一半的文件在系统层面还在吗?在底层还在吗?...



来源:知乎

链接:https://www.zhihu.com/question/55711728(点击尾部阅读原文前往)



知乎问题:

断电时文件系统发生了什么?硬盘又发生了什么?下一次开机时写到一半的文件在系统层面还在吗?在底层还在吗?

更进一步的, 文件系统如何保证事务性, 会不会存在某种极端情况导致例如最后几个bit还没写完, 文件系统却认为它成功了的情况?

回答不限任何文件系统,谢谢!

作者「北极」的回答:

断电的一瞬间,很多事情是无法确定的:

1.你无法确定你试图向设备驱动发送的写指令是否成功,驱动程序本身一般都有缓存;

2. 即使写指令正常返回,你也无法确定设备实际上是否写成功,因为设备本身可能也有缓存。目前没有设备能保证写指令返回的情况下,所有数据一定成功的保存在介质上(但部分厂商能保证少量数据一定能成功写入),对存储设备的flush操作并非绝对可靠;

3. 哪些成功哪些失败可能是乱序的,换句话说,如果先发送写请求A,再发送写请求B,并且都成功返回,掉电时请求A可能丢失,但B成功(NCQ功能);

4. 机械式磁盘可能会出现丢失半截数据的情况(比如,一个512字节扇区只写入了100字节,也就是题主说的bit级错误),但这种一般都会通过校验位检测出来。

因为有以上这么多的限制,实际上文件系统一般没办法保证数据一定不丢失,甚至哪些丢失哪些能恢复也是不确定的。

一般来说,文件系统有以下的几种策略:

1. 完全不管错误的事情,错了就错了;

2. 打标记位的方式,如果怀疑有错,通过磁盘检测功能恢复;

3. 在设计上保证文件系统结构上可恢复,但不保证用户数据可恢复;

4. 能在用户数据层面上保证数据的绝对正确。

第一种和第二种策略现在比较少见,FAT文件系统算是属于这类;主流文件系统基本上都能保证第三种,比如NTFS之类的;第四种比较难,一般都要配合存储驱动一起,多见于Flash介质的专属文件系统。

保证数据不损坏,具体的方案一般有:

方案1:Copy-On-Write,写数据的时候不在原来的位置写,而是先读一份,然后写到另外一个位置,当确认写成功时,把文件系统的指针指向新的位置。如下图:
实际应用中,比这个情况复杂,因为Data2写入的过程中,File1本身的一些信息(修改时间等)也发生了变化,所以CopyOnWrite产生的影响不止这一个块,而是很多。

方案2:日志(Journal)技术。使用日志记录meta-data甚至是数据块的变化情况(NTFS就是这种策略),一旦出现掉电情况,在日志中反推到一个正确的状态上,就可以保证meta-data不损坏。

常见的方案就这两种,当然还有别的更复杂的技术,可以参考这个链接(Comparison of file systems),但不管用什么方案,本质上都是以牺牲性能为代价换取结构上的稳定。

最后回到题主的问题,文件系统如何保证数据的正确性?如果是指文件的数据部分,是无法保证的,因为文件系统无法确定数据到底写没写进去,绝大多数文件系统只能保证自身结构是正确的,但这个正确可能是回滚之后的状态,具体回滚多少内容,文件系统自己也不能保证。

这事说起来挺复杂的,不同文件系统,不同设备,不同介质,效果都是有区别的。

作者「马涛」的回答:

文件系统的设计一般是性能和数据完整性的妥协,如果你想要最高完整性,那么性能会差一些,如果你想要最高性能,那么数据完整性会差一些,仅此而已。当然这些都是针对数据而言的,对于文件系统自身的元数据,一般设计者为了自身数据完整性的考虑都会有日志系统(比如ext4使用jbd2),从而尽量保证文件系统在断电时没有问题或者问题很少(需要使用fsck来解决),但是用户数据是否完备是由用户选择和配置的,而文件系统会根据不同配置选择不同的策略。

我们以Linux最通用的ext4为例,他有三种模式供用户选择data=writeback/ordered/journal,对应的是数据落盘的三种方式,writeback是指元数据更新的时候数据不考虑是否落盘,所以掉电以后可能会看到一些乱七八糟的数据,ordered的意思是元数据更新在数据更新之后(如果你没有更改元数据那就没有办法保证数据了),还有一种是journal意思是数据也先写journal再写文件(double write),这种数据安全性最高,当然性能也最差。详细的介绍可以参加mount(8)。

说完文件系统,我们再说硬盘,硬盘在文件系统下面,所以文件系统是重度依赖硬盘来实现数据完整性的,而硬盘也提供了一些命令来保障文件系统数据完整性的语义。比如硬盘会提供flush命令,保证只要上层文件系统调用了这个命令,那么文件系统之前写到硬盘里面的内容必须落盘了(一般的硬盘有内存cache,为了提高写入性能会缓存一部分数据,flush会命令硬盘将cache内容落盘。当然如果硬盘如果有电容可以保证cache即使掉电也会落盘,那么他也可以欺骗上层的文件系统 :) ),这样文件系统在写入一些关键数据以后必须调用flush,在得到硬盘的flush反馈以后再进行后面的工作。当然现代硬盘还有一些FUA(Force Unit Access)之类的操作,这些是为了加速某类磁盘落盘的操作,本质上即使硬盘不提供文件系统可以改成write+flush来实现(只是性能差一些),如果感兴趣大家可以自行google之。

说完底层,还有一层要说一下,就是你的应用是怎么写文件和硬盘的,如果是buffer write(应用只写到操作系统的内存,由操作系统延迟回写到硬盘),那么很大可能你在掉电之前一段时间写入的数据都会不见了(操作系统还没有回写),如果应用是direct IO(应用绕过操作系统内存,直接写硬盘),那么可能只有掉电时刻正在写入的数据不见了,当然这里可能还涉及到direct IO的语义以及不同文件系统的具体实现,和文件系统相关,就需要具体问题具体分析了。

●本文编号2286,以后想阅读这篇文章直接输入2286即可。

●输入m可以获取到文章目录
本文内容的相关公众号推荐
Linux学习↓↓

黑客技术与网络安全↓↓

更多推荐15个技术类公众微信


涵盖:程序人生、算法与数据结构、黑客技术与网络安全、大数据技术、前端开发、Java、Python、Web开发、安卓开发、iOS开发、C/C++、.NET、Linux、数据库、运维等。


    关注 程序猿


微信扫一扫关注公众号

0 个评论

要回复文章请先登录注册