“新司机”虽然上路了，但并不知道走了多少弯路，因为还知道有没有走上正路。但上路也快一年了，当然有一些体会，就算是错的，也该想过些什么。如果我什么体会都不写出来，那么这些想法总会在我的脑子中绕啊绕啊的。所以我希望写些出来，也许这样就可以不用刻意提醒自己不要忘记它们，也好专心”开车”。而且我想，车技总是不断积累联系和回看总结的过程，也许我将来看现在自己的体会，不是嘲笑自己的车技太差就是羡慕自己的没有迷路运气。当然还有一种情况，就是我能因这些感想能将其他”新司机”带上(歪)路，我也是很欣慰的。。。
这系列文章，不去反省自己的缺陷，不去叙述自己的经历，只写下当前所总结的体会。本篇博客，我将写一下对存储栈的理解。后边，我还可能从存储组织(文件系统/存储结构)、存储缓存和虚拟化存储等几方面写下体会。
1. 层次化封装
就像OSI网络参考模型一样，存储也是有层次的，如果在网络中我们将这些层次称为网络协议栈(TCP/IP协议栈)，那么在存储中我们经常用存储栈(storage stack)或I/O栈(I/O stack)与之对应。
顾名思义，栈这一种直上直下一层叠一层的结构。在网络的层次中，数据链路层关心的是MAC地址，网络层关心的是IP地址，栈中的所有层次分工协作，大家像流水线一样将数据层层传递如下图。
在存储层次中，也有类似的分工。比如以Linux存储栈为例，文件系统主要关心的是文件的组织结构，向上将接口暴露给用户；而文件系统下一层的块存储设备层则关心实际数据的去向，主要和存储设备打交道。下图是一个单机上比较复杂的情况，以一个运行在KVM虚拟机中的MySQL为例。当然如果考虑远程网络分布式存储，应该更复杂。
2. 为什么层次是必要的
除了网络和存储，其实编程语言中封装的这种概念，在我看来就类似这种层次化的形式。比如在很多编程语言中常用的SHA256、MD5等安全Hash算法或者链表、各种常用数据结构的库等。这节的问题就以编程中的封装和层次开发为例进行说明。
对编程语言的库来说，问题在于，既然哈希算法的计算方法都是开源的，数据结构都是固定的形式，为什么不自己写呢？首先想到的可能是自己写费时费力，其次一个被很多人使用的库一般都是由各路大神优化而来，应该比自己实现的效果要好，但最重要的，库是可以复用的。
比如那么当我们在这些其他人实现的库的基础上构建自己的应用的时候，就是在库的封装之上进行的开发，这就形成了库-->我的应用的这样的层次结构。进一步说，如果我们是在其他人的库的基础上开发了更高层的库，比如我在其他人写的二叉树库的基础上开发了用于排序的库，那么我们的封装层次就又涨了一层：二叉树库-->排序库-->其他人的应用。再展开说，我们甚至可以冲破一种编程语言的界限，表示出更完整的封装层次：数字逻辑-->指令集-->汇编语言-->系统调用-->编程语言标准库-->二叉树库-->排序库-->其他应用。
如果只是从左到右或者从上到下画出这种层次图，我们还是无法理解层次的必要性，但是如果我们想横向扩充，这种层次就是很必要的。极端的情况：如果我们所有的层次都重叠在一起，那么也许我想开发一个gui小应用，就要从汇编开始，一直沿着操作系统改到库和应用逻辑，简直不现实，这也是软件工程中耦合和内聚的概念。换句话说，不论我们是靠近硬件还是靠近应用的程序员，我们都可以从自己出发，只要向上层和下层提供不变的接口，那么不论我们在自己的范围怎么折腾，都不会破坏其他层次的工作。
回到存储，我们只有将管理文件的file system和下层的设备驱动通过块设备层和虚拟文件系统(VFS)层解耦，才能在单独编写多中设备驱动不用再去修改文件系统代码，也才能在添加新的文件系统功能的同时不用担心对老的设备是否可以工作。
3. 为什么层次可能影响性能
还是以编程语言为例，很多都认可C语言相对其他语言是高效的，但学汇编的人可能觉得汇编才是最高效的，这都没有错，汇编比C高效，但并不属于高级程序语言，C比Python高效，但是指针这种东西没有谁可以一时半会搞定。实际上，汇编–>C–>Python就可以认为是这样封装起来的。某种程度上来说，我们开发C语言应用可以看成是和开发Python是在一个层次上的。。。对于存储也是一样的，层次总是一层一层网上堆的。堆到越上层，越具有其简单易用的特性，而这种层次化页必然会带来性能上的降低。
现在在我看来，存储层次升高带来的性能损失的根本原因是因为在层次间信息的不对称的同时还有些层次要越层”搞事情”。具体来说，层次之间的沟通通过接口，由于层次间较松的耦合，某一层中无法获知其他层中的具体细节。比如，应用程序可能要告诉文件系统具体要读的文件名，但并不知道文件具体存在什么地址；文件系统可能告诉块设备驱动它具体要读内容的地址，但是块设备层就不知道这内容属于什么文件了。
但是，存储的管理不光“你告诉我你要什么数据，我把数据传给你”那么简单：首先，由于数据的重要性，各个层次都要用自己的机制保证数据的完整性和一致性；其次，也要利用数据的局部性，用dram作为cache来弥合内存和二级存储设备间的性能差异。那么大家都要保证数据可靠，大家也都在加把劲降低IO读写延迟，真的是齐心协力力量大吗？
当然大家都想整个系统变得更好，但是既然层级之间信息不对称，一定会因为缺少合作，而导致自己所做的工作不如预期，甚至起到副作用。我们是需要加强各层间的耦合交互？还是提升各层的“智能”让其揣测其它层的想法？还是应该聘请一个“存储栈独裁程序”来统一发出号令？这块儿学问就大了，还是新司机的我理解并不够深入，车技提升后还要展开多写写。。。
4. 在适当的层次做适当的事
Python认为程序员要指针没啥用，于是没有设计出指针的概念。而可能在一些C语言程序员眼中，Python因此就是一种有缺陷的语言。但是我们可能忽略了一点，就是没有谁禁止过Python程序员学习C语言，也没有人禁止过C程序员学Python。对于一个项目来说，没有最好的语言，只有最合适的。
对于存储层次同样如此，比如同样是数据加密，我们可以在应用程序中加密数据，可以在文件系统中加密数据，可以在数据网络传输之前进行，极端的情况，甚至也可以在硬盘硬件中进行加密。对于cache，我们可以在应用层开辟内存作为cache、或者利用文件系统缓存，或者磁盘的硬件缓存等。选择很多，不同的功能，适合的位置也是不同的，同样和上节一样，这块儿学问就大了，还是新司机的我理解并不够深入，车技提升后还要展开多写写。。。