“写放大”(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] […]

出于某种目的,你可能不想把levelDB的所有的文件都存到一个目录下: 我们希望的: level 0 -+ level 1 +–> DIR1 (DISK1) level 2 -+ —————————— level 3 -+ level 4 | … +–> DIR2 (DISK2) level N -+ 但是 levelDB 不支持类似的选项,只能将文件存到一个目录;而且不幸的是,levelDB由于频繁的compaction操作,带来了频繁的文件创建和删除,且每个level包含多个文件,不易这样改。 我想到的方法有两个:(1) 用基于levelDB改进的RocksDB,它支持多路径。(2)修改levelDB源代码。为了更简单的实现我们想要的分level存到不同目录的功能,我们从levelDB存储的最底层“创建文件”步骤,利用软链接进行修改。 本文将首先介绍levelDB的目录结构,然后分析给出介绍这两种文件更改路径方法。 1. 目录结构 创建一个DB后,和这个DB相关的所有数据都会放在一个文件夹的多个文件中。这些文件包括xxx.ldb、xxx.log、LOG、MANIFEST-xxx、LOCK、CURRENT等。这些解释在[1]中说的都很清楚,我可以用中文再解释一遍。 日志文件 xxx.log xxx.log文件包括是最近存储的数据序列,所以是大小是乱序的,当xxx.log文件达到一定的大小(默认4MB),就会被转换成Sorted tables有序表文件。这个日志文件对应内存中当前的memtable,当这个memtable满了后,会被写到level-0,对应的xxx.log文件会被删除,新的xxx.log会被生成,对应于新的memtable。 有序表文件(SSTable) xxx.ldb SST是Sorted Strings Table的缩写,levelDB中,对应的文件格式是ldb。xxx.ldb文件中的KV记录是按key的大小排好序的。随着数据量增加,ldb文件有很多。但是,它们文件名前缀数字、文件大小都与所属的level无联系(文件名即文件大小都不包含level语义),所以我们无法从文件名和文件大小判断出某个文件中数据所处的level。不过,一个文件只可能属于一个level。 除level-0外,各个level的文件总大小是预先设定的,level-1 10MB,level-2 100MB, level-3 1000MB……;而level-0较特殊,其由文件个数限制,默认达到4个level-0 ldb文件就会merge到level-1中;而且,level-0中的数据可能有重叠存在。 清单文件 MANIFEST 我们从xxx.ldb文件名和大小无法判断其所属level,那么就要有一个额外的文件存储这些“元信息”。MANIFEST-xxx文件就负责存储哪个文件属于哪个level,每次打开这个DB,都会新建一个清单文件并标一个特殊的后缀作为标记,其中的内容也是以log-structured形式追加存储的。 当前文件 […]

大部分截图来自原书,贴出书的官方主页: 《Operating Systems: Three Easy Pieces》 (作者Remzi H. Arpaci-Dusseau and Andrea C. Arpaci-Dusseau)。感谢原作者这么好的书。 本篇笔记是书的第三部分(Persistence),讲述了操作系统和外存系统相关的内容。 第一节 I/O Device 1.1 IO 总线 一般情况下, IO设备的性能较差(慢),所以用Peripheral IO Bus,为什么不用像显卡一样用的PCI呢?因为1)越快的总线越短,这样空间不够插;2)越快的总线制作成本越高,如果存储设备照总线的性能差的远,没必要用高性能总线。 这张图为总线的层次结构,memory bus是最快的也是最近的,IO Bus比较远,也是最慢的,中间有用于显卡的PCI等总线。 1.2 典型设备的组成部分 一个典型的外围设备如图所示,包括两部分: 接口 和 内部结构 。 接口: 类似软件接口的功能,硬件接口是留给OS和设备交互的。 内部结构: 比如㓟CPU、MEM等基本组件,还有称为固件(firmware)的软件来实现内部功能。 1.3 两种IO模式(Polling和Interrupt) Polling的形式,而interrupt。 一种典型的协议是 Polling (轮询),称为programmed IO,步骤有4: 循环等待STATUS寄存器直到设备状态为不busy 写数据到DATA寄存器 写命令到COMMAND寄存器 循环等待STATUS直到设备为不busy Polling显著的缺点就是太浪费CPU时间,这是因为IO相对于CPU是很慢的,大量的CPU时间被用在了等待上。 Interrupt (中断)方法(也称为interrupt-handling IO)可以解决这个问题,用Interrupt方法进行IO时,当设备完成操作时,会raise一个硬件interrupt。但是这样的话,如果设备很快(比如现在的NVMe SSD设备),Interrupt由于需要进程上下文的切换、以及中断的控制等原因,会拖慢IO的速度。所以两种方法各有利弊: Polling […]

“新司机”虽然上路了,但并不知道走了多少弯路,因为还知道有没有走上正路。但上路也快一年了,当然有一些体会,就算是错的,也该想过些什么。如果我什么体会都不写出来,那么这些想法总会在我的脑子中绕啊绕啊的。所以我希望写些出来,也许这样就可以不用刻意提醒自己不要忘记它们,也好专心”开车”。而且我想,车技总是不断积累联系和回看总结的过程,也许我将来看现在自己的体会,不是嘲笑自己的车技太差就是羡慕自己的没有迷路运气。当然还有一种情况,就是我能因这些感想能将其他”新司机”带上(歪)路,我也是很欣慰的。。。 这系列文章,不去反省自己的缺陷,不去叙述自己的经历,只写下当前所总结的体会。本篇博客,我将写一下对存储栈的理解。后边,我还可能从存储组织(文件系统/存储结构)、存储缓存和虚拟化存储等几方面写下体会。 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、或者利用文件系统缓存,或者磁盘的硬件缓存等。选择很多,不同的功能,适合的位置也是不同的,同样和上节一样,这块儿学问就大了,还是新司机的我理解并不够深入,车技提升后还要展开多写写。。。

时隔近3个月,我本科毕业后第一次回到了西安,见到了在本校读研的舍友们,不过主要还是来参加信息存储年会的。 会议有特邀报告、青年学者报告和优秀论文交流报告,分别是大神级的学者、大神级的青年学者和大神级的博士生进行报告,听了这些报告真的感觉到自己的差距有多么大,同时感觉不虚此行。 这是一篇我所听报告的部分内容的总结,语言从我个人理解的角度出发,信息可能不全或不准确,如有问题,欢迎讨论和指正。 阻变存储器性能优化方法的研究 冯丹教授讲的题目是“ 阻变存储器性能优化方法的研究 ”。首先RRAM(阻变式存储,Resistive Random Access Memory,ReRAM)是一种非易失性存储器(NVM),尺寸单元小,有发展潜力。冯丹教授这次的报告是比较偏硬件,但还是有很多启发。 背景: DRAM在技术上要降低能耗、提升容量越来越难,而且DRAM技术提高的速度比CPU慢,另外技术工艺达到40nm之后很难再提高。所以ReRAM代替DRAM是一种选择。 RRAM的存在的问题: 1. reset延迟和能耗代价均高于set;2. TLC的延迟大于SLC;3. 存在IR-drop的问题,离驱动电源越近,延迟越低。 几项工作: 1. 针对上述第一点问题,提出了可以将对角线上的set和reset并行,这样降低了总延迟时间。 2. 针对上述第二点问题,使用了一种“压缩率感知”的方法,利用MLC/TLC中中间几种状态慢于两边状态的特点,将中间的几个状态合并,根据压缩的工作负载的压缩率,来进行决策,重新编码存储(比如把原来MLC的4中状态中的第2、3两种合为一个状态,这样就变成了3中状态,减小了延迟和能耗)。3. 针对上边的第三点问题,用双端驱动代替单端驱动,这样处于接近电源驱动的区域就增多了,并且可以根据快慢在驱动层中区分硬件上的快慢区域,来合理使用。 半层次化的语义存储体系结构 华中科大华宇教授的报告,讲了一种” 半层次化的语义存储体系结构 “,希望将原来的存储结构(比如文件系统的目录结构)转为一种多标签的索引结构。 背景: 存储有5个趋势,分别是更大规模、智能化、一体化(计算和存储更近)、长期化和边缘化(雾计算,临近计算等)。 问题: 存储的层次化越来越明显,同时新兴的存储期间很多(PCM、SSD、DRAM、3D Xpoint……);NVM能缓解存储的压力,但是由于寿命等问题无法从根本上解决问题;对于文件系统来说,查找树不是太高就是太胖;locality的设计思想是用稀缺资源存储最热的数据,但目前的大趋势是locality正在减小;cache的适应能力弱,比如需要较强时间的预热,代价很高。 解决思路: 用语义存储带起当前的存储模式,例如:文件系统中使用扁平化的树结构,一个文件同时贴上(识别出)多种标签;有了这种模式,非精确dedulication中可以在关联数据间进行,提升效率;近似图像语义间的dedupe;data cube是对于高维查找提前做出计算的一种方法,如果基于语义,可以缩小计算范围。 数据中心驱动下KV系统的设计和实现 德州大学阿灵顿分校的Song Jiang教授主要讲了KV系统的缓存问题。 问题: 由于在分布式存储中,所有的访问都要经过metadata server(MDS),所以MDS是一个瓶颈,应用Key-Value(KV)系统就是取消了MDS的一种解决方案。KV系统是需要缓存的,怎么更高效的利用有限的缓存空间是一个问题。 思路: 可以使用更好的缓存数据替换算法,但是并没有效果太好的;可以提升内存容量,但是这会直接导致成本上升;可以利用压缩提升缓存利用率,但是解压和压缩也会导致很大的性能下降。 方法: 对实际访问trace数据分析发现,随着缓存空间的增长,缓存命中率上升到80%是很快的,但从80%上升到90%则需要更多的内存,基于这点,将cache分级,最热的数据不进行压缩,对并非太热的数据进行压缩,这就很好的平衡了压缩解压缩的延迟和缓存的利用率问题。 对于这种方法,还有一个解释,就是对cache命中,即使要进行解压缩操作,时间也远远小于访问存储服务器进行磁盘访问,这样,即使缓存利用率提升了5%,也可能带来很大的性能提升效果。Song教授解释的意思是,由于磁盘访问的速度特别慢,在命中率从90%提升到95%的情况下,更应该看到的是未命中率降低了一半(10%–>5%),而不是命中率提升了很少(90%->95%) 其他 清华的陆游游博士介绍了NVM+RDMA的分布式存储方案,有了RDMA,CPU传送所有数据的等待时间减小到传送存储地址的时间。 华科博士生左鹏飞提出了一种基于位置分享的解决哈希冲突的策略,用于NVM系统。 上海交大的博士生董明凯介绍了他发表在ATC 17上的文章Soft Updates Made Simple and […]

“时间”和“空间”,在小的时候对我来说只是两个词语,没有什么实质的领悟;后来知道了霍金曾写《时间简史》来讨论时间,到现在也没读完过,估计读完也懂不了;貌似爱因斯坦还说过时间是现实世界的第四个维度?但时间对于人来说总是有别于空间的,但时间总是感觉很特别,感觉不应该和空间统一起来,我想两者应该是个对等的关系;再后来,相见别离,让我明白了时间的意义,房价飙涨,也让我了解了空间的残酷(2333…)。 倒是从大学后的一些课程开始,我对这两个概念有了更加现实的理解。比如,数据结构这门课貌似从第一节就让我们求一段程序的空间复杂度和时间复杂度,有些算法是用时间换空间(牺牲更多计算时间,减少存储空间),有些是用空间换时间。加上后来的各种经历和获得的知识,让我觉得,信息的存在需要空间和时间,而随着人类的发展,各种信息所需要的时间和空间之间可以互相转换替代。 生活中的信息和时间/空间 如果对算法复杂度一窍不通,我们也能在生活中找到一些例子。比如街上的小店铺门前挂的LED电子屏幕,上面可能滚动着各种最新的促销信息,如果你碰巧感兴趣,就需要驻足等所有字幕滚动一遍。看完你可能觉得很烦:“为什么字幕滚动这么慢,促销又这么没有诚意,完全是在浪费时间…”,这说明你的阅读速度很快,老板也许还想让更多心不在焉的人感受到他跳楼甩卖之决心呢。我们考虑这样一个问题,如果放到没有LED屏的30年前,也许把整个店铺的店面用横幅盖住也写不下这么多的字吧。这里,LED电子屏减小了店铺广告的空间,却增加了展示同样多信息的时间(不考虑人的阅读速度,时间由零秒变为字幕滚动所需的数秒)。 类似还有很多例子。我还可以想到电子书和纸质书,一个iPad可能可以存下原来一个图书馆的书籍,空间大大减小。但是要展示所有的书籍的信息,iPad却必须花时间:设想我们有足够的空间的话,可以把图书馆所有的书的每一页都撕下来摊开放在地上,所有信息展示的时间为零,而iPad只有一个屏幕,我们无法在一个时刻翻完所有的信息(假设屏幕帧率为100Hz,我们一秒最多翻100页)。再例如,如果你喜欢电子读物,只需要一个MP3和一个耳机,甚至连ipad的大屏幕都不需要,空间又减小了,但由于说话速度小于阅读速度,展示完所有信息需要的时间却又增加了。这里当然是把人接收书中信息的速度忽略不计了,因为有人会把音频书加快3倍听,而另一些人可能看文字书一目十行。 更接近信息本质的思考 在通信和计算机系统中,信息的传递和存储都是需要编码的,这些编码的过程就是对信息进行表示和压缩的过程。 莫尔斯码也许是为人熟知的系统,这种电码和现代计算机系统类似,最小的通信单元也是两种状态:长、短。长短电报音的各种组合就能表示各种各样不同的信息。最早的电报是需要电报员的,他只能戴上耳机,处于紧张的接收状态。设想如果我们是21世纪的操纵古老电报机的电报员,我们可能会想出各种办法把这种音频记录通过模式识别之类的手段存储起来,然后用Python写一个解码器就直接将翻译过来了。我们不考虑翻译过程的话,我们的“现代做法”便是用存储空间换取了持续在线接收的时间,或者说这是一种带不带“缓冲区”的区别。 数据压缩的概念也很常见,我们从网上下载的很多文件,格式都是rar或zip的,这时如果你想使用它,就必须用压缩软件解压。而这个解压速度,主要取决于你CPU的计算性能。很简单的道理:解压和压缩虽然都需要消耗时间,但可以节省更多的空间。这就是信息在时间和空间的一种转换。 信息的成本和价值 “时间就是金钱”。我认为,之所以人们经常那这句话提醒自己,肯定是因为通常金钱并不经常和时间有一个公认的“汇率”。也许空间就不一样了,在北京的房子可能需要10万一平米,其他有些地方的房子可能只要1千元一平米,大家都觉得很合理;一块普通硬盘可能需要5毛钱1GB的成本,可能固态硬盘就要5块钱1GB,大家也认为很合理,空间总有个价格。 …… 如果我假设,信息的产生、获取或者存储可以用存储空间和计算时间来度量,同时计算时间和存储空间之间又存在某种公认的价格(比如云计算–明码标价的计算能力和存储能力),那么也许时间就是真的可以用金钱来衡量了。而信息这种依赖时间和空间的产物,也便产生了其必然的价值。那么到了那个时候,时间就是金钱,金钱就是信息。 …… 最后要说明: 这篇博客并没有投入很多时间深入思考,只是最近偶然冒出的一些想法。在我看来,人生的意义很大程度上在于了解自己和自己之外的东西,这些想法也许有用也许没用,也许深奥也许通俗,但以我的角度,都是自己所学所见的一些积累所导致,所以对我来说都是值得记录的。谢谢大家的关注。

原文: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喊道。 “一个全新的互联网”,可爱的程序猿Richard说。 “我们曾用一台掌上电脑的计算能力把一个人放在月球上”,Richard继续说道,“我们现在手机上的计算能力要比那强几十万倍,但这些手机却都只是躺在口袋里什么都不做。所以我想到这个,有数十亿的手机在世界各地拥有相同的计算能力,只是闲在人们的口袋里。“ “然后我想,如果我们使用这些手机来构建一个庞大的网络呢?使用我的压缩算法来使一切数据变得很小,高效,到处传播。如果我们能做到这一点,我们可以建立一个完全去中心化的网络,那将是没有防火墙,没有收费,没有政府监管,没有间谍的互联网。信息因此在各种意义下都将是完全自由的。“ Russ不仅喜欢这个看似疯狂的想法,还答应投资。Russ还分解了Richard的数据压缩初创公司Pied Piper,迫使他退出,以便让他弄清楚如何将“新互联网”变成现实。 “我不知道是否可行”,Richard承认,“我还没有仔细去想过。” 这正是观看剧集的粉丝们一直想知道的, Richard的“新互联网”到底是真的可能呢,还是只是电视上编造的? 当今的互联网是去中心化和中心化的混合体。 任何人都可以创建一个去中心化的点对点(P2P)网络,让设备间直接连接,比如BitTorrent。同时,任何人也可以去创建一个中心式网络,通过服务器传递数据,多数大型在线服务都是如此,如Google,Facebook和Twitter。 加密的、去中心化的网络的好处是显而易见的:安全性和隐私性。 由于数据在分散的网络节点上存储和传递,没有任何在线服务或者政府可以在你不知情的情况下窥探你的数据。 Mesh Network 理论上,可以有几种方式来构建这个“新互联网”。 第一个是Mesh Network(网状网络),它是由任意数量的设备或节点组成,数据在节点之间传递。手机应用Firechat是使用mesh network的完美示例,它通过蓝牙让手机间相互连接。 事实上,一些狂热的reddit用户在《硅谷》下一集的预告视频中Richard的白板涂鸦上发现了一些线索,表明剧中他至少考虑了mesh network。使用mesh network并依赖蓝牙等无线协议的缺点当然是较小的覆盖范围和较慢的传输速度。你的设备与其他设备的连接质量要取决于各个设备的蓝牙规格。虽然你可以通过你和你要连接的设备的路径中间有其他节点“中继”来解决这个问题,但并无法保证每次都有中间节点。 另一方面,蓝牙4.0只有200英尺的范围,蓝牙5.0的新设备也能达到800英尺。此外,蓝牙5.0将带宽从4.0的25Mbps提高到50Mbps。虽然不如千兆的Wi-Fi或LTE,但嘿,隐私和安全更比速度更重要,对吧? 也就是说,剧中Richard的能“使一切都变小,高效”的超级强大的压缩算法,将是使mesh network成为可能的特殊要素。 Maidsafe & Storj Richard实现他宏伟计划的另一种可行方式,是像Maidsafe的SAFE网络或Storj的P2P网络。虽然它们仅用于去中心化的文件存储,但我并不认为像Richard那样的代码狂人无法调整这些结构。SAFE网络自称为“新的去中心化互联网”,很大程度上承诺了Richard的想法,只不过它没有使用闲置的手机计算资源,而是使用的PC。 根据该公司的说明,用户可以无须验证地创建一个帐户,然后决定贡献分配给SAFE网络的空间。 然后,Maidsafe会向贡献存储空间的用户支付“Safecoins”(一种具有真实市场价值的加密虚拟货币)。用户向“vault”贡献越多的存储空间,就会得到越多的Safecoins。Maidsafe以此来进一步激励用户加入SAFE网络。 在文件被上传之前,它被先被加密,然后分解成较小的数据包并分散到网络中去。数据存储是存在冗余的,并且在计算机打开时,文件会在网络上自主移动。简单说,“新互联网”上所有的数据都是分块、加密存储在所有设备上的。在网络上所有设备上的碎片加密件中。 当你需要访问自己的数据时,只需从其他设备下载各部分就可以了,这基本上就和BitTorrent一样了。 SAFE网络现在只是在进行alpha测试,但是更接近公开发布。 虽然它只适用于Windows/Mac/Linux,但公司未来也会考虑移动平台。去年在TechCrunch上,Maidsafe创始人David […]

论文原文PDF: sRoute: treating the Storage Stack Like a Network 出处:USENIX FAST 16 1. 概述 数据中心中,数据从一个应用最终到达存储服务器不仅要经过网络,还要经过很多的存储层次,这些层次可以称为存储栈(Storage stack)。对于数据中心中一个较为复杂的应用,一个IO请求甚至要经过应用缓存层、虚拟机操作系统(Guest OS)文件系统页高速缓存、Guest OS文件系统、Guest OS IO调度层、Guest OS块缓存、Guest OS块设备驱动、虚拟机管理器、宿主机操作系统(Host OS)网络驱动、缓存服务器、远程存储服务器缓存、远程存储服务器文件系统、远程存储服务器物理磁盘等多达十几层的存储阶段(Stage)。 而一般IO经过这些stage最终到达终点的路径是预先制定好的,这条路缺乏灵活性(hard-coded),即使仅想改变其中的某个stage,实际更改的时候也可能会涉及到这个stage之上和之下的多个stage。 本文仿照软件定义网络(SDN)的思想,提出了一种软件定义存储的架构sRoute,从原始的数据中心存储中心抽象出数据平面和控制平面,控制平面上的中心化controller随时可以对数据平面上的存储交换机sSwitchs安装“转发规则”,来实时控制IO路径。这样,就实现了包括改变终点、改变中间路径和将点对点路径散布为一点对多点在内的三种基本IO路径更改方法。 2. 整体设计 2.1. 数据平面和sSwitch 数据平面包括原有IO栈的各个stage和本文新加入的特殊stage sSwitch。sSwitch可以插入到IO路径的中任意的stage中,其根据当前的”IO转发规则”对IO进行转发。具体的,sSwitch会检测每个IO请求的header,根据header中包含的IO源点和目的点信息来和当前sSwtich所存的”IO转发规则”进行匹配,然后根据对应规则进行转发。 例1 把所有从VM~1~中到服务器S~1~文件X的读请求都路由到S~2~文件Y,那么VM~1~和S~2~之间的任意一个sSwitch的转发规则可以这样表示: