存储 on 涯余的博客

JFFS3 文件系统

hang.yan@hotmail.com (涯余) — Sat, 20 Apr 2019 22:35:17 +0800

看完了闪存,继续看文件系统。网上搜了一圈，发现都是讲 Andriod 的目录结构的，讲文件系统本身的少。目前能确认的是历史上曾经用过 ext4,yaffs,yaffs2 等。估计目前主流的应该是 ext4。不过在搜索的时候先发现了一篇讲 jffs3 的，它在嵌入式系统上应用比较广泛，也是针对 Flash 存储特定设计的文件系统。不太确定现在的使用范围，但是拿出来研究下还是不错的。

闪存对文件系统的影响

闪存跟磁盘有很多不同的地方，在设计文件系统的时候，二者有很多不同的考量。简单的对比表格如下

	闪存	磁盘
最小寻址单位(读)	字节	扇区
最小寻址单位(写)	NOR FLASH 是字节，NAND FLASH 是页，擦除是块	扇区
寿命	由擦写块的最大可擦写次数	机械故障

闪存的这些特性，导致我们在设计文件系统的时候，必须考虑以下的问题：

out of place update: 对于磁盘来讲，我们更新数据可以直接原地更新。但是闪存不行，因为无法将 bit 位从 0 -> 1。所以对于闪存的数据更新只能是在另外一个地方写入数据，然后将原数据标记为 dirty,再通过 GC 来定期回收.
wear leveling: 磨损平衡。闪存的使用寿命是由擦写块的最大可擦写次数来决定的。超过了最大可擦写次数，这个擦写块就成为坏块(bad block)了。因此为了避免某个擦写块被过度擦写，以至于它先于其他的擦写块达到最大可擦写次数，我们应该在尽量小的影响性能的前提下，使擦写操作均匀的分布在每个擦写块上

闪存转换层

为了能让普通的文件系统(磁盘上的)能够在闪存上正常运行，需要有一个转换层：Flash Translation Layer（FTL）。它的功能就是将底层的闪存模拟成一个具有 512 字节扇区大小的标准块设备(block device)。对于文件系统来说，就像工作在一个普通的块设备上一样，没有任何的差别。

闪存

hang.yan@hotmail.com (涯余) — Thu, 18 Apr 2019 21:01:13 +0800

本来看华为新弄了 FS 和编译器，想学习下。但是目前似乎放出来的技术资料并不多，就先做下技术储备。先研究下他们做这个优化的历史背景。一路看下来发现链路太长，EXT4、更早的文件系统、最后到了闪存。大学课堂上学过，但到现在真要考我，估计也说不出个所以然，所以先记录下闪存相关的笔记。

基本定义

ROM 的一种，虽然看着是read only，但是闪存属于的细分类别已经可以允许重写数据(EEPROM)。比较接近的两种细分类别对比来看：

EPROM: 需要用紫外线照射才能重写数据(注定要被淘汰的技术)
EEPROM: 多的一个E便是Electrically，可以用电擦除数据

自然 EEPROM 的应用更加广泛。目前手机上的存储主要就是闪存（EEPROM)。闪存用于手机等移动设备的一些原因如下:

动态抗震性好(没有机械部件)
极端环境下也比较可靠(手机三防)
在擦除数据时比一般的 EEPROM 效率更高(区块对字节)

NOR / NAND

两种 flash 的类型，直接上一个比较简单的表格对比：

	NOR	NAND
抹写速度	慢	快
抹写次数	低	高 (10x)
存取方式	随机	区块
成本	高	低
面积	大	小
适用场景	微处理器	普通存储
实际使用	BIOS/机顶盒	U 盘/SSD

写/擦除

这也是一个容易忽略但是细究起来很容易让人迷惑的东西。为什么闪存有擦除的概念? 简单来讲，由于闪存特殊的物理构造，可以理解为写操作只能写入0,擦除操作相当于写入1。手机闪存和固态硬盘为什么擦除多了会损坏？这篇文章提供了具体的电路图示意：

Shard

hang.yan@hotmail.com (涯余) — Fri, 11 Aug 2017 21:37:39 +0800

介绍

Shard 指对数据的水平切分,每一个切分的部分都可以叫做一个shard,它们拥有相同的 schema,但却拥有不同的数据集。对数据库来说，是指对数据库的表按行进行切分(与按列的垂直切分对应)，不同的 shard 可能位于不同的数据库服务器或者物理机器上。它的优势体现在以下几点:

表的大小减少,索引体积减小,提升查询性能(某些方面)
如果数据本身有比较明显的分区(比如国家,地区等),那么做 shard 很容易并且查询很大程度上都能落在一个 shard 上。
水平扩展性好，可以通过添加新节点来扩充

劣势有以下几点:

查询需要跨多个 shard 时会增加 latency
因为 shard 经常只能做到某一位维度。所以在这一维度的查询的性能可能提高，但其他维度的查询的性能则可能会下降。
跨 shard 的数据一致性和可用性也更加复杂和难以保障

shard 本身的问题让他成为一个迫不得已的选择。尽量在没有其他优化方式的情况下选择 shard.理想情况下，应该有底层框架来处理 shard 而让应用层做到对 shard 无感知，不然还不如不用。

分片策略

如果将数据集进行 shard,有很多策略可以选择，常见的有

The Lookup strategy

用 shard key 做一个映射表，包含不同 shard key 的请求会转发到相应的 shard 上。这种情况下，不同 shard key 的数据可能会落在同一个 shard 上，但相同 shard key 的数据则一定在同一个 shard 上.shard 与物理地址的映射也不能是一对一的，可以用类似于 consistent hashing 里面的那种 virtual node 的方式，设置一些virtual shard，几个 virtual shard 可以对应于同样的物理位置(reblancing 的时候对上层代码的影响很小)。