掉电保护功能对SSD的数据安全作用有多大？机械硬盘有带断电保护的吗？

ssd掉电保护使得在突然断电的时候能有足够的时间把高速缓存中的数据移动到存储颗粒中。

它的实际作用还是很大的，避免了很多由于突然掉电而导致的文件丢失或者文件系统损坏等等情况。

机械硬盘也有断电保护的。不过机械硬盘的掉电保护只是保证在断电的情况下磁头能及时归位，从而避免磁头划伤盘片而造成的损坏。

是一项数据安全技术保护。

x系统由于出色的性能和稳定性，而广泛受到计算机业界的关注和应用，但在使用的过程中，难免遇到意外断电或文件损坏的情况。

会导致数据的丢失，甚至有可能导致系统无法正常启动，为了给用户提供完善系统，在设计的过程中添加掉电保护功能，这也使掉电保护的作用越来越受到重视。

LittleFs设计之初的重点特性是：

（1）低资源消耗；

（2）掉电保护；

（3）擦写均衡，

本章节重点讨论第（2）和（3）这两个特性，第（1）个特性则贯穿在整个设计过程中。后文把LittleFs简称为lfs。

最经典的掉电保护方法有两种，一种是使用日志，一种是通过COW方式。lfs结合了两种方法，并优化了两种方案的缺点，提供了一套掉电保护策略。

具体步骤为：

（1） 写入数据之前，先在日志区存储开始标志，记录要写入的数据位置和大小；

（2） 待写入的数据写入日志区；

（3） 待写入的数据写入数据区；

（4） 写入完成之后，在日志区记录结束标志。

模拟掉电场景：

（1） 步骤1完成，步骤2没有完成；重启之后，保持原来的数据，日志无效；

（2） 步骤1，2完成了，步骤3没有完成，尝试把步骤2的数据写入到数据区；

（3） 步骤1,2,3完成了，步骤4没有完成，同样尝试把步骤2的数据写入到数据区；

具体步骤为：

（1） 想更新节点F的数据，先申请一个新的节点，把F的旧数据拷贝过去，然后更新新的数据；

（2） 把父节点的指针指向新的节点，去掉旧节点的指针。

模拟掉电场景：

（1）步骤（1）完成了，步骤（2）没有完成，则使用旧的数据，新的节点变成孤儿节点。

lfs结合了日志方式和COW机制两种方式进行掉电保护，并且优化了两种方案。

前面谈过文件系统三要素，超级块，inode，以及数据。对应lfs来说，他把超级块以及inode通过日志的方式存储，两种采用统一的存储结构，后文称两者为元数据；普通数据则采用cow的方式存储，采用czt逆序链表的方式。

元数据（对应root，dir）采用双block的方式存储，互为备份，每个block都有一个revision序号，值越大，表示block的数据越新，每个block默认可以存储最多0xff个文件的数据，如果超过这个值，则需要compact（压缩）。

Compact是干什么呢？ 即当数据的大小大于某个值的时候，把数据整合，剔除同一个id的旧的数据，然后写入到备份block里面。

在compact的过程中，如果发现整合的数据还是大于某个值，怎么办呢？需要split（分片）。

Lfs的数据采用ctz链表的方式逆向管理，这与传统的文件系统有比较大的差别。具体对比见下图所示。

传统的方式添加数据，需要建立旧的数据到新的数据的索引。这样做有两个弊端：

（1） 当数据特别多的时候，这样一个个的索引过去查找，比较费时间。

（2） 当使用cow机制的时候，在文件后面每增加一次数据，需要把所有的索引都重新建立一个，这样带来的性能损耗特别大。

为了解决这两个问题，lfs采用了下面的管理方式。

指针的建立采用了CTZ(二进制中最后一个不为0的位，其右边0的个数)的方式。大概原理就是，block N 如果是一个能被 2^X整除的数，那么他就存在指向N – 2^X的指针，指针的数目为ctz(N)+1。

了解擦写均衡之前，先需要知道littlefs是怎么管理物理block的，怎么才能申请到一个空闲的block。

为了节省内容，Littlefs对空闲block的管理采用了滑窗方式，滑窗的大小是可以配置，默认是32bit，对应32个block的使用情况。

当文件系统需要申请一个空闲的block的时候，从lookahead中寻找没有置位的block，申请成功，则给对应的block位置1。当当前的窗口中的所有block都被占用的时候，就需要滑动窗口了，一次性滑动窗口大小的距离，即默认一次滑动32个block。

一片flash的总的block是有限的，假设其序号从0->N，lookahead对应的block范围是I->J，Littlefs会通过lfs_fs_traverse遍历所有使用到的block，如果这个block在I->J之间，则说明block被使用了，否则就是空闲的。

通过前面的滑窗机制，可以一定程度上的避免每次 *** 作到的都是同一个片区的block。但是这还不够，因为每次启动的时候，滑窗都是从block0开始滑动的，这个会导致前面的block使用频率高于后面的block。所以，我们需要找到办法，让每次启动的时候，滑窗的位置都是随机的，极致的随机，就是平均了。

为此，littlefs使用了crc作为随机数，再通过简单的运算，得到了滑窗启动的时候的起始位置。

问题又来了，crc哪儿来的，干什么的？

Crc就是元数据提交的终结符号，用来校验提交是不是正确的，littlefs借用了crc之间相互异或带来的不确定性来作为滑窗的启动地址，一定程度上复用了现有的机制达到了随机的目的。

写入流程：

读取流程：

---