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采用了下面的管理方式。
（1） 采用逆向的指针，这样常规的追加数据，不需要额外的开销来重新建立所有的索引；
（2） 每个偶数block有多个指针，指向更远的数据，这样可以在检索的时候加快速度。
指针的建立采用了CTZ(二进制中最后一个不为0的位，其右边0的个数)的方式。大概原理就是，block N 如果是一个能被 2^X整除的数，那么他就存在指向N – 2^X的指针，指针的数目为ctz(N)+1。
从上表可以看出，block 2多一个指向0的指针，block 4多一个指向0,2的指针。
咱们已经知道了实际数据（对应file）采用czt list的方式存储，最新的数据block指向次新的数据block（这个是为了提高COW的效率）。
一次常规更新数据的过程大概为（实际比这个复杂很多，需要考虑cache、孤儿、crc等问题）：
（1） 往file文件中写入数据；
（2） 申请一个新的block，并且把file文件最后一个block的数据复制到新的block，并追加要写入的数据；
（3） 更新新block的czt list（在block的头部会占用一定的4字节倍数的字节来记录索引，这个czt list只是用来fseek的加快速度）；
（4） 文件fclose的时候，更新对应的元数据信息到父节点中。
掉电保护的具体场景：
步骤（1），（2），（3）完成了，但是（4）没有完成。因为索引还没有建立起来，数据虽然写入了，但是没有人知道，文件系统会丢失最新的数据，保留修改之前的数据。
步骤（4）过程中掉电了。步骤（4）是更新元数据，元数据采用了主备的方式，并且采取了如下的格式：
正常的提交流程为：
（1）提交tag；
（2）提交data；
（3）提交crc。
当tag和data提交了，但是CRC没有提交的时候，crc就会校验失败，这个时候前面crc校验通过的部分，就会被relocate到一个新的块，这样由于断电导致的数据异常，则回退成功。注意：crc校验的时机，在提交一个新的commit到对应的元数据的时候。
了解擦写均衡之前，先需要知道littlefs是怎么管理物理block的，怎么才能申请到一个空闲的block。
为了节省内容，Littlefs对空闲block的管理采用了滑窗方式，滑窗的大小是可以配置，默认是32bit，对应32个block的使用情况。
当文件系统需要申请一个空闲的block的时候，从lookahead中寻找没有置位的block，申请成功，则给对应的block位置1。当当前的窗口中的所有block都被占用的时候，就需要滑动窗口了，一次性滑动窗口大小的距离，即默认一次滑动32个block。
当窗口滑动了之后，lookahead中又有了新的空闲的block可以申请。
问题来了，怎么定义一个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之间相互异或带来的不确定性来作为滑窗的启动地址，一定程度上复用了现有的机制达到了随机的目的。
写入流程：
读取流程：
