“写放大”(Write Amplification)在存储系统中是很常见的。但是,即使都是在存储系统中,“写放大”也有很多种,各种的写放大原理并不是很一样。下边根据自己的理解,进行了下总结,如有问题,恳请指正。 1. 读写单元较大导致的写放大 在文件系统中,读写单元固定,比如都是4K,这样,如果write函数写的数据小于4K,则要先把整块读入,再修改,再把新的4K整体写入(O_DIRECT情况除外)。这个过程可以称为 RMW (Read-Modify-Write),这就是File System的写放大问题。[1][2][5] (注意:Read-Modify-Write被更广泛地用在原子指令[3]和RAID[4]中。) 再如,在DBMS等应用层存储系统中,同样存在自己管理的读写单元,如MySQL的默认读写单元称为页,默认是16KB,所以一次读写只能以页的单位进行,这时,小于页的数据读写同样会带来整页的读写,进而造成了“写放大”,道理和文件系统是一样的。 2. RAID中的Read-Modify-Write造成的写放大 如前段所述,RAID中更新一个块,需要额外读原始块、校验块,额外写校验块,所以多了两个读,一个写,也称为Read-Modify-Write[4]。 这是由于校验块必须更新,且根据异或运算的可逆性,新校验块=新数据块^旧校验块^旧数据块。 3. SSD中闪存特性造成的写放大 在SSD中,一个block可以分为多个page,在读的时候,可以以page为单位,但是写的时候,只能以block为单位。因此写的单元比较大。在上层(比如文件系统)读写单元相同的情况下,同样是读写1个page的大小,读的话直接读就行,写的话却需要先把与要写page同一个block的数据全复制一遍,加上修改的page后,再一起写入block。写入的数据量远比实际的大,这就是SSD的写放大问题。 4. 存储系统一致性机制造成的同步写放大 在存储系统的很多层次中,都有保证系统crash consistency(一致性)的设计。因此,不管是应用层的存储系统(如DBMS、KV-store)、虚拟化层中的镜像管理、系统层的文件系统,甚至是硬件层的SSD FTL[7],都要通过强制同步各种元数据的写入顺序,或者利用redo log的思想,用journaling、log-structured或copy-on-write等策略保证元数据写入目的位置生效前先完整地生成日志,来保证系统崩溃或断电时,元数据之间是一致。但是,如果多层存储系统重叠,由于一致性机制导致同步次数增加就会层层放大。 比如,运行在x86虚拟机中的levelDB,其一次更新操作就会(1)最终导致levelDB写log文件和写数据两次同步写,这两次写就又会(2)导致2次的Guest文件系统log写和2次Guest文件系统数据写,一共4次同步写,这4次写又会导致(3)虚拟化镜像管理层的4 x N次写(N取决于镜像为保证元数据crash consistency的同步次数,若是qcow2格式,N可能有5次之多[6]),最后导致(4)Host文件系统的4 x N x 2 = 8 x N次同步写。当然这是一种比较极端的情况,但实际应用中也应该存在。 5. 基于LSM树的KV系统的Merge操作造成的写放大 levelDB等KV存储广泛采用了LSM树等结构进行存储组织,其特点就是靠上的level的数据会最终被merge sort到下层,由于多数level在磁盘文件中,这也就导致了同一KV数据的总写放大,放大的倍数就是大约是level的数目。和前边4中写放大不同的是,这种写放大并非写操作时马上就会发生写放大,而是写操作发生时会潜在的导致“未来会发生”写放大,所以这种写放大只会导致整体写代价提升,不会影响实时的延迟性能,只可能会影响磁盘带宽或者在SSD做存储设备时影响闪存耐久。FAST 16上有篇论文也专门分析了这种写放大。[8] [1] Why buffered writes are sometimes stalled, http://yoshinorimatsunobu.blogspot.com/2014/03/why-buffered-writes-are-sometimes.html [2] Block size and read-modify-write, https://www.spinics.net/lists/linux-xfs/msg14456.html [3] […]

欢迎评论。。以后还可能写个版本2。。。 冗余的人类语言 研表究明,汉字序顺并不定一影阅响读!事证实明了当你看这完句话之后才发字现都乱是的。 以上这句话很多人都看到过,知乎上也有很多人讨论问题的原因[2],对于这段中文,有人从贝叶斯决策的角度分析,指出这是由于人借助了上下文的相关信息+日常的经验。对于英文,如果把一段话的每个单词的字母顺序打乱,也会出现不影响阅读的情况,有人指出这可能是人在阅读一个单词时只看第一个字母和最后一个字母的原因。我感觉都是有道理的。 但现在我们要从另一个角度考虑这个问题: 假设在另一个平行宇宙中,汉语“研表究明”和“研究表明”存在截然不同表示的是两种截然不同的意思,那么就算那个宇宙中的人们可能就觉得这两个词是有区别的。 再假设一个更极端的平行宇宙,他们每个单词都长为6个字母,且只能由ABCDEF 6种字母组成(我算了下有4万多种组合,够多了),那么,他们对词序的判别应该就特别严格吧。 可见,我们所在的平行宇宙中,语言中是存在“冗余”的。这样,不管依据什么经验,语言的冗余,让我们辨识出调换词序的句子的原本意思成为可能。 其实不光调换词序体现了这种冗余。类似的,当我们在一个噪音大的环境中讲话的时候,或者在FM收音机中调出一个信号不好的电台时,我们一般情况下照样可以听明白对方所讲,靠着也是这种“冗余”,我们可以根据已知的信息,猜出完整的信息。 0和1:抗干扰的冗余 接着说收音机。如前边所说,我们的语言中存在”冗余”,所以接收的电台中音调偶尔的变化或者一些字的不清晰依然不影响我们接受信息。那么为什么现在的网络电台没有这些失真、底噪呢,人们靠什么高科技来消除这些噪声干扰? 我们常见的收音机,不管是调幅的还是调频的,都是以模拟信号进行传输的,这种信号直接将要传输的信息以幅度或者频率的形式均匀地映射(调制)到负责传输信号的电磁波(载波)上,由于传输的过程(信道)中信号必然是被各种干扰(噪声)的,于是我们的收音机接收到的电磁波转换到声音的形式(解调)时,干扰信号(噪声)也就被一一映射到了声音(噪音)传到我们耳朵中。 但是现在的网络传输,多数基于数字信号。信号都不再是一一映射到频率值或幅度值了,而是仅映射为一个由0或1(两种频率或幅度)组成的编码。我们假定一个最简单的串行通信,在一个时刻,只能有0或1两种可能,假设信道中存在干扰(比如0被干扰到0.2还会被认为是0信号,1被干扰为0.9还会被认为是1信号),接收后的结果也大概率没有出错。其实这也是一种冗余,一种防止出错的冗余。 0, 1, 2, 3:高效的冗余? 我们为了信息的稳定传输,将无限种状态映射到两种状态(0和1)的编码。但是,我们为什么一定要2种状态呢?为什么不能是0, 1, 2三种状态呢?如果这种可能容易实现(电路上),而且人们最开始没有走上普及二进制计算机这条不归路,那么可能我们现在用的都是基于三机制的电脑了[4]。 技术上的难度或者转换的巨大成本,让人类点了”二进制”这条科技树。不过人们虽然没有用3种状态,但是用4种状态或者8种状态的情况倒是有很多,因为这能保证了和系统其他部分的二进制组件兼容。 比如在信息存储中,固态硬盘(SSD)的MLC/TLC技术,就是在每个存储单元中把以前SLC的两种状态(电压)记录信息,转为用4种/8种电压来记录信息,这样做便增加了SSD的存储密度。 (0, 1, 2, 3) + X: 不可避免的冗余 但是,这种4种或8种状态的SSD,虽然提高了存储密度,但它们的存储单元的寿命会缩短,所以制作这种SSD的时候,就一定要在设备内部预留更多的备用存储单元,这也是一种冗余。看来冗余从抗干扰的冗余被迫转为空间的冗余。 当然,我们也可以采用校验/纠错码技术,用更小的空间冗余来保证信息的可靠。但是编码或数据恢复都需要话费额外的计算时间。如果我们比起冗余空间的开销,更不看重数据恢复的时间,那么看起来空间的冗余又转为了时间的冗余。 看来,冗余无法避免,0/1到(0, 1, 2, 3),虽然它们减少了信号抗干扰的冗余,但是最终也无法避免的使用了其他的冗余。X可能是空间,可能是时间,但到今天这个世界中,都会是money,无法预测的money。 扩展阅读 [1] 熵:宇宙的终极规则, http://www.ruanyifeng.com/blog/2017/04/entropy.html [2] 知乎:为什么汉字顺序有时候不影响阅读? https://www.zhihu.com/question/20428571 [3] 知乎:如何从心理学上解释『打乱英语单词首尾字母之外的字母顺序仍然不影响阅读』的现象?https://www.zhihu.com/question/20804531/answer/16237704 [4] 知乎:苏联三进制计算机Сетунь到底是怎样一个计算机?https://www.zhihu.com/question/35937929

手动搜集资料,不敢保证无误,如有错误,恳请指正。 1. 设备 最新的3D XPoint存储器比DRAM慢10倍,便宜2倍;比NAND FLASH快1000倍,贵5倍左右,性能比其他PCIe和NVMe的SSD快10倍左右。并且它是一种NVM。 下表摘自[2] Type Volatile? Writeable? Erase Size Max Erase Cycles Cost (per Byte) Speed SRAM Yes Yes Byte Unlimited Expensive Fast DRAM Yes Yes Byte Unlimited Moderate Moderate Masked ROM No No n/a n/a Inexpensive Fast PROM No Once, with a device programmer n/a n/a Moderate Fast EPROM No Yes, […]