Consistency这个词在计算机各领域用的很多，比如分布式系统、体系结构和存储系统等等。本文只探讨存储系统crash consistency。Crash Consistency问题在存储系统中都会存在(数据库、文件系统、dedup系统 …)，即系统遭遇断电、崩溃等情况时，相关联的数据没有全部持久化可能导致的不一致。本文以文件系统为例进行说明，所有内容基于自己对相关资料的理解，如有错误，恳请指正！
下表整理自我的OSTEP笔记[1]，我们假设了一个有data和inode、bitmap两种metadata的简单文件系统，下表给出了一些可能导致不一致的情况，其中N表示断电时没有写完，F表示断电时已经完成：
“写放大”(Write Amplification)在存储系统中是很常见的。但是，即使都是在存储系统中，“写放大”也有很多种，各种的写放大原理并不是很一样。下边根据自己的理解，进行了下总结，如有问题，恳请指正。
在文件系统中，读写单元固定，比如都是4K，这样，如果write函数写的数据小于4K，则要先把整块读入，再修改，再把新的4K整体写入（O_DIRECT情况除外）。这个过程可以称为 RMW (Read-Modify-Write)，这就是File System的写放大问题。[1][2][5] （注意：Read-Modify-Write被更广泛地用在原子指令[3]和RAID[4]中。）
再如，在DBMS等应用层存储系统中，同样存在自己管理的读写单元，如MySQL的默认读写单元称为页，默认是16KB，所以一次读写只能以页的单位进行，这时，小于页的数据读写同样会带来整页的读写，进而造成了“写放大”，道理和文件系统是一样的。
出于某种目的，你可能不想把levelDB的所有的文件都存到一个目录下：
|
1 2 3 4 5 6 7 8 9 10 |
我们希望的： level 0 -+ level 1 +--> DIR1 (DISK1) level 2 -+ ------------------------------ level 3 -+ level 4 | ... +--> DIR2 (DISK2) level N -+ |
但是 levelDB 不支持类似的选项，只能将文件存到一个目录；而且不幸的是，levelDB由于频繁的compaction操作，带来了频繁的文件创建和删除，且每个level包含多个文件，不易这样改。
大部分截图来自原书，贴出书的官方主页： 《Operating Systems: Three Easy Pieces》
(作者Remzi H. Arpaci-Dusseau and Andrea C. Arpaci-Dusseau)。感谢原作者这么好的书。
本篇笔记是书的第三部分(Persistence)，讲述了操作系统和外存系统相关的内容。
一般情况下， IO设备的性能较差(慢)，所以用Peripheral IO Bus，为什么不用像显卡一样用的PCI呢？因为1)越快的总线越短，这样空间不够插；2)越快的总线制作成本越高，如果存储设备照总线的性能差的远，没必要用高性能总线。
“新司机”虽然上路了，但并不知道走了多少弯路，因为还知道有没有走上正路。但上路也快一年了，当然有一些体会，就算是错的，也该想过些什么。如果我什么体会都不写出来，那么这些想法总会在我的脑子中绕啊绕啊的。所以我希望写些出来，也许这样就可以不用刻意提醒自己不要忘记它们，也好专心”开车”。而且我想，车技总是不断积累联系和回看总结的过程，也许我将来看现在自己的体会，不是嘲笑自己的车技太差就是羡慕自己的没有迷路运气。当然还有一种情况，就是我能因这些感想能将其他”新司机”带上(歪)路，我也是很欣慰的。。。
这系列文章，不去反省自己的缺陷，不去叙述自己的经历，只写下当前所总结的体会。本篇博客，我将写一下对存储栈的理解。后边，我还可能从存储组织(文件系统/存储结构)、存储缓存和虚拟化存储等几方面写下体会。
就像OSI网络参考模型一样，存储也是有层次的，如果在网络中我们将这些层次称为网络协议栈(TCP/IP协议栈)，那么在存储中我们经常用存储栈(storage stack)或I/O栈(I/O stack)与之对应。
时隔近3个月，我本科毕业后第一次回到了西安，见到了在本校读研的舍友们，不过主要还是来参加信息存储年会的。
会议有特邀报告、青年学者报告和优秀论文交流报告，分别是大神级的学者、大神级的青年学者和大神级的博士生进行报告，听了这些报告真的感觉到自己的差距有多么大，同时感觉不虚此行。
这是一篇我所听报告的部分内容的总结，语言从我个人理解的角度出发，信息可能不全或不准确，如有问题，欢迎讨论和指正。
“时间”和“空间”，在小的时候对我来说只是两个词语，没有什么实质的领悟；后来知道了霍金曾写《时间简史》来讨论时间，到现在也没读完过，估计读完也懂不了；貌似爱因斯坦还说过时间是现实世界的第四个维度？但时间对于人来说总是有别于空间的，但时间总是感觉很特别，感觉不应该和空间统一起来，我想两者应该是个对等的关系；再后来，相见别离，让我明白了时间的意义，房价飙涨，也让我了解了空间的残酷(2333…)。
倒是从大学后的一些课程开始，我对这两个概念有了更加现实的理解。比如，数据结构这门课貌似从第一节就让我们求一段程序的空间复杂度和时间复杂度，有些算法是用时间换空间（牺牲更多计算时间，减少存储空间），有些是用空间换时间。加上后来的各种经历和获得的知识，让我觉得，信息的存在需要空间和时间，而随着人类的发展，各种信息所需要的时间和空间之间可以互相转换替代。
如果对算法复杂度一窍不通，我们也能在生活中找到一些例子。比如街上的小店铺门前挂的LED电子屏幕，上面可能滚动着各种最新的促销信息，如果你碰巧感兴趣，就需要驻足等所有字幕滚动一遍。看完你可能觉得很烦：“为什么字幕滚动这么慢，促销又这么没有诚意，完全是在浪费时间…”，这说明你的阅读速度很快，老板也许还想让更多心不在焉的人感受到他跳楼甩卖之决心呢。我们考虑这样一个问题，如果放到没有LED屏的30年前，也许把整个店铺的店面用横幅盖住也写不下这么多的字吧。这里，LED电子屏减小了店铺广告的空间，却增加了展示同样多信息的时间(不考虑人的阅读速度，时间由零秒变为字幕滚动所需的数秒)。
原文：The technology to make ‘Silicon Valley’s’ decentralized ‘new internet’ already exists( http://mashable.com/2017/04/24/is-silicon-valley-new-internet-possible-or-not/#6cEY_p263PqN )
作者：RAYMOND WONG
时间：APR 25, 2017
“给你无限的时间和资源，你想用你的压缩算法做出什么都行……什么都行，说出来是什么，3，2，1……说！”美剧《硅谷第四季》中的“变态”亿万富翁Russ Hanneman对主角Richard Hendricks喊道。
论文原文PDF: sRoute: treating the Storage Stack Like a Network
出处：USENIX FAST 16
数据中心中，数据从一个应用最终到达存储服务器不仅要经过网络，还要经过很多的存储层次，这些层次可以称为存储栈(Storage stack)。对于数据中心中一个较为复杂的应用，一个IO请求甚至要经过应用缓存层、虚拟机操作系统(Guest OS)文件系统页高速缓存、Guest OS文件系统、Guest OS IO调度层、Guest OS块缓存、Guest OS块设备驱动、虚拟机管理器、宿主机操作系统(Host OS)网络驱动、缓存服务器、远程存储服务器缓存、远程存储服务器文件系统、远程存储服务器物理磁盘等多达十几层的存储阶段(Stage)。