排版不好，请包涵。待完成后后一定出一个干净的合集。

2 控制流分析

2.1 控制流图

控制流图是对程序中分支跳转关系的抽象，描述程序所有可能执行路径，定义如下：

图2.1控制流图

控制流图的节点是语句集合，从A到B的边表示语句A执行完后可能直接执行语句B，整个控制流图必须有唯一的入口和出口。这是以每个语句为节点的控制流图，实际操作的控制流图一般以基本块(basic block)为基本节点，每个基本块包括若干条语句，基本块本身有唯一的入口和出口。

2.2 Dominator和Post-dominator

在控制流图中，Dominator描述节点之间在实际执行轨迹中的顺序关系。如果A是B的Dominator，那么意味着从程序入口执行到B的任意路径则一定经过A，称A Dom B，定义如下：

图2.2 Dominance关系定义

Dominance关系具有自反(x Dom x)、传递(x Dom y 且 y Dom z，有x Dom z)和反对称(x Dom y不意味着y Dom x)等性质。如果x Dom y且x!=y，那么称x是y的strict dominator。进一步的，如果x是y的strict dominator(记为Dom!)，并且对任意除x以外的y的任意dominator w，有w Dom x，那么称s是y的immediate dominator(记为IDom)，直观上，immediate dominator就是dominance关系链上最近的一个。Post-Dominator和Dominator是对偶的，如果x PDom y，那么任意从y到程序出口的路径都必须经过x。

考察dominator关系对一些程序分析很有价值。如检测对变量的初始化语句是否出现在所有对该变量的使用之前，或者在多线程程序中检测是否每一个lock都对应unlock。

根据Dominator关系的上述定义，任意一个节点都有唯一immediate dominator。如果把控制流图中所有其余的边删掉，只保留immediate dominator边，就得到一颗dominator树。给定控制流图，只要求得其dominator树，就能得到节点间的所有dominator关系。下图2.3给出了一个Lingo程序以及对应的dominator树：

图2.3 dominator树举例

接下来的问题，给定控制流图，如何快速找到所有dominator关系，图2.4是一个基本迭代算法：

图2.4 dominator关系求解算法

首先初始化，entry节点的dominator集合初始化为一个元素(entry自身)，所有其他节点的集合初始化为整个节点集。接下来进入迭代过程，每次迭代考察每个节点，将该节点所有前驱的集合求交集，整个迭代过程直到解不变为止(即不再有新的Dom关系添加进来)。这个算法不关心不同节点的计算顺序，但事实上由于节点间的依赖关系，合理计算顺序对整个dominator关系求解的性能至关重要。

考虑图2.5的深度优先遍历过程：

图2.5 DFS过程中的先序和后序编号

遍历过程中对节点升序编号，可见有两种基本的方式：先序(pre-order)和后序(post-order)。直观上，分析dominator关系应该采用先序，因为前驱节点应该尽可能先处理，但对于有环(循环)的控制流图仍可能需要多次迭代。直接采用后序违反直观，对任何节点，前驱节点处理之前无法完成处理该节点。但如果将后序倒过来(reverse post-order)，就能确保任意节点在其后继节点之前处理。reverse post-order不同于pre-order，更多的分析可以参考文献[1]。

Dominance Tree的高效计算方法如图2.6所示。算法基本框架和图2.4一样，需要留意几点细节。首先初始化时，对入口节点外的节点不是初始化为节点全集而是初始化为空(undefined)。进入迭代过程每轮循环需要遍历所有节点更新dominance关系，对所有节点(入口节点无需处理)采用reverse postorder来顺序处理。对选定的待处理节点b，首先选择第一个处理过(processed)的前驱，所谓处理过就是doms[b]不再是Undefined状态的节点，这一点很重要，否则有环时算法可能终止不了,接下来就是遍历所有处理过的前驱寻找b的immediate dominator，这一步通过intersect(b1,b2)实现。

intersect()过程中的变量都表示后序(post order)的节点编号，目标是找到b1和b2最近的公共前驱节点的编号，内层两个while循环按照reverse postorder的顺序找到reverse postorder编号小 (即postorder编号大) 的公共节点。图2.6的算法给每个节点找到其唯一的immediate dominator，所有这些信息合起来构成一颗dominance tree。

图2.4和2.6的算法都是从入口节点(entry node)出发构造dominator关系集合，一组节点的信息被分析出来的前提是从入口可达，因此这两个算法都分析不到死代码(从入口节点无论什么路径都无法到达)内的dominance关系。这点关系不大，因为人们一般只关注死代码的位置，对其内部结构兴趣不大。

图2.6 Dominance Tree算法

2.3 控制依赖

控制依赖直观上很好理解，但在控制流图的准确定义存在需要注意的细节，定义如图2.7所示。

图2.7控制依赖的定义

这就是说节点y和x之间存在控制依赖需要满足三个条件。第一个条件即存在一条x到y的执行路径P；第二个条件进一步要求x到y之间没有其他控制语句，换言之对路径P上的任意节点n，n到出口的任意路径上一定经过y，也就是说y是n的post dominator。第三个条件要求y一定不是x的strict post dominator，直观上就是说在x和y之间一定有一条流程控制语句，进而使得除了从x到y之外一定还会有跳转到其他地方的路径。例如图2.8所示的程序中，语句5控制依赖于语句4，但语句6和语句4之间没有直接的控制依赖关系，因为4和6直接的语句5是一条控制语句。但另一方面，语句6,7,8都控制依赖于语句5，语句7 PDOM! 语句6，语句8 PDOM! 语句7。

图2.8 控制依赖举例

2.4 循环和强连通子图

控制流分析的另一个应用是检测循环。对控制流图进行深度优先遍历(DFS)能得到一个生成树，生成树中边叫forward edge。另外还有两种边：cross edge和backward edge。backward edge表示控制流图中存在循环。问题是如何区分cross edge和backward edge，下面以图2.9中的程序为例来说明。

图中每条语句用数字标出，显然从语句8到语句3的边回到循环条件，构成回边(backward edge)。语句6到8和语句7到8分别有一条边，这两条边只有一条可能出现在DFS遍历的生成树中，剩下的一条就是交叉边(cross edge)。假设有一条从A到B的边，判断其是交叉边还是回边的方法是：如果在生成树中可以从B到达A，那么该边是回边；否则是交叉边。

图2.9 循环举例

从另一个角度，控制流图中的循环本质上构成了图中的一个强连通子图(Strong connected component)。检测图中强连通子图的标准算法是Tarjan算法，如图2.10所示。

Tarjan算法只需要对图进行一次深度优先遍历即可完成，需要O(n+m)的复杂度，其中n是边数目，m是顶点数目(算法中有对每个顶点的栈操作)。preorder按照优先遍历的顺序对节点编号，n.order表示节点n自身的编号，n.root表示n所在循环根节点的编号，算法先初始化节点所在的根为节点自身的编号。接下来首先顺序处理n所有邻接节点，然后更新n的根节点编号，原因在于可能存在从n的邻接节点到祖先节点(编号可能比n小)的回边，这一步确保能找到最大的强连通子图。递归处理完所有邻接节点后，由每个连通子图的根节点输出该子图的所有节点，每输出一个节点，就将该节点“删除”，这样确保任何节点只可能出现在一个强连通子图中，即不可能出现多个子图交叉的情况。

还有一个实现上的细节：当找到并输出该连通子图的所有节点时，需要子图中每个节点的root域(即让子图中每个节点指向新的根)。如果在图2.10中，repeat/until循环体中增加一个语句才会更准确：v.root = n.order。这样确保连通子图中每个节点的root域指向其所在子图的根节点，否则在存在嵌套循环的时候会有问题。

关于Tarjan算法原理的更多细节请参考文献[2]，关于该算法的实现细节请参考本文第二部分基于Clang的实现参考源码。

图2.10 检测强连通子图的Tarjan算法

2.5 自然循环和可化简控制流图

自然循环(natural loops)就是只有单一入口的循环。两个自然循环要么完全不相交，要么嵌套。对于没有goto语句的语言，所有的循环都是自然循环。一般循环可能存在多个到循环体的入口，如通过goto语句直接跳转到一个循环的循环体中。

如果一个控制流图仅通过如下T1和T2两种变换能化简为一个节点，则称该控制流图是可化简的(reducible)：

1. T1: 如果节点n有唯一的前驱，那么将其和其前驱合并为一个节点；
2. T2: 如果节点存在到自身的边，那么将该边删除。

没有循环的控制流图都是可约简的，对存在循环的控制流图，当且仅当所有循环是自然循环时此图是可化简的。有一些程序分析算法只对可化简的控制流图有效。

[1] Keith D. Cooper, Timothy J. Harvey and Ken Kennedy. “A Simple, Fast Dominance Algorithm”. Software: Practice and Experience, 2001; 4:1-10.
[2] Esko Nuutila, Eljas Soisalon-soininen. “On Finding the Strongly Connected Components in a Directed Graph”. Information Processing Letters, 1994.

这段时间由于工作中涉及到内存疯长的事情，工作之余就对比分析了tcmalloc和ptmalloc的一些工作方式，关于ptmalloc代码的分析，已经有前人做了不少的工作，我这边主要讲述一下，我对tcmalloc的一点理解，写的比较随意，难免漏洞百出，有问题希望大家能够指正（email:huangjiangwei@gmail.om）开始写写还行，写到后面就不想写了，所以后面的章节代码多于评论和分析，自己都不想看下去了。
Tcmalloc通过preload或者直接动态链接的方式对malloc等内存分配和释放函数进行截获并提供服务。Tcmalloc提供接口主要涵盖malloc.h的接口。下面我将通过内存操作的基本流程，从分配开始到释放简单的分析tcmalloc的一些内部实现。

首先我们来看内存的分配。在tcmalloc中，内存分配malloc的入口为tc_malloc，new的入口为tc_new，相应的realloc，calloc，memalign，valloc等也有相应的入口。先简单描述一下tcmalloc的malloc过程和free过程。

Malloc过程

1、               Tcmalloc首先判断malloc的size是否大于kMaxSize（8u * kPageSize为32k），如果小于这个值，那么将size转换为想的obj class，然后从当前thread私有的cache中Allocate，转至第2步。如果请求的size大于kMaxSize那么跳至第10。

2、               首先判断当前的threadcache中obj calss对应的freelist中是否包含有空闲的obj，如果有直接pop出来，否则从CentralCache中拿，转下一步。

3、               CentralCache和ThreadCache之间obj的转移采用batch方式，每次转移固定数量的obj，这个数量通过Static::sizemap()->num_objects_to_move定义，当然在决定最终转移数量时还是需要不能超过ThreadCache相应list的maxlength。然后通过CentralCache对应freelist的RemoveRange函数将确定大小的obj转移出来，并通过对应list的PushRange函数将这些obj插入ThreadCache对应的freelist。

4、               CentralCache通过RemoveRange将特定数量的obj移出，CentralCache将连续的内存看做一个Span，Span是CentralCache管理内存的一个主要数据结构。而Span又被切分成N个统一大小的obj。每个CentralCache管理属于某个特定class的obj。在同一个CentralCache中所包含的obj大小符合特定calss的要求。CentralCache包含kNumTransferEntries（kNumClasses）个slots，这些slots用来存储正好包含num_objects_to_move个obj的Span。如果slots满了或者包含其他数量obj的Span将统一放入两个Span队列，empty和nonempty。这里的名字比较诡异empty函数存放的Span不是空闲的Span而是Span里面没有空闲obj的Span，nonempty则相反。

5、               因此在Allocate的过程中，首先判断需要Allocate的obj数量是不是正好符合num_objects_to_move，如果是而且CentralCache用来存放span的slots不为空，那么直接从slots里面拿，否则从nonempty队列中的Span拿。

6、               Nonempty队列存放了所有可用的Span，那么从头开始一个个拿，如果拿光了还是不能满足要求，那么只能通过向pageheap要求一个span，这个span的size由class_to_pages决定，然后再将这个Span切成obj返回给CentralCache。然后再次尝试从Span分配。

7、               Pageheap管理整个系统page级别的allocate，他通过两个数据结构管理所有的Span（free_数组和large_列表），free_数组存放size小于kMaxPages（1 << (20 – kPageShift)256）的Span，而large_列表存放大于等于kMaxPages的Span。PageHeap首先判断要求的pages是否大于等于kMaxPages，如果小于那么先从free数组中找，从要求大小的位置开始往后找，先找normal队列在找return对队列。如果在normal队列中找到且找到的Span状态为Span::ON_NORMAL_FREELIST，那么直接从里面切出需要的Span返回给CentralCache。如果在return队列中找到且找到的Span状态为Span:: ON_RETURNED_FREELIST那么直接从里面切出需要的Span返回给CentralCache。

8、               如果需要的size不符合上述要求或者在上述队列中没有找到那么将从large_队列中找。从large_队列中查找时，首先从normal队列入手，然后再从return队列找，他将找到size最符合且地址在空闲Span中最小的Span，然后切出来返回。

9、               如果large_队列中都没有找到合适的Span，那么将通过GrowHeap增长Heap的方式，通过TCMalloc_SystemAlloc向系统申请不小于1M的内存。并包装成Span，并插入heap中，然后再次进行分配。

10、           来到此处代表分配的内存是大于32k的，那么将向heap直接请求跳到第7步。

Free过程

1、             首先free根据提供的ptr指针，获得此ptr所在的页面，然后利用页面号，获取需要释放的obj的size，这个size首先从pagemap_cache_中拿，如果不在pagemap_cache_中那么直接通过页面好获取所在的span，如果span为NULL，那么直接报错返回，否则通过span获取需要释放的obj的size，并将size和page的关系放入pagemap_cache_。

2、             如果能够获取ptr所指obj的size，且本释放是在子线程内（可以获取threadcache），那么调用threadcache的Deallocate释放，转到一下步。否则利用InsertRange直接将obj插入Centralcache对应size的freelist。如果ptr所指的obj size为0，有可能是大的obj，直接从pageheap中拿的，那么跳第5步。

3、             Threadcache通过相应的size获得对应的freelist，然后通过push将obj链入freelist。如果插入之后的list太长将通过ReleaseToCentralCache将num_objects_to_move个obj返还给CentralCache，如果整个threadcache的size太大，那么将对整个free数组进行遍历，调用ReleaseToCentralCache函数。

4、             ReleaseToCentralCache将通过对应CentralCache的freelist调用InsertRange将需要返还给CentralCache的objs插入CentralCache。CentralCache判断所返还的obj数量是不是正好等于num_objects_to_move，如果是且slots_里面有空闲区，那么直接返还给slots_，否则将这些obj返回给相应的Span，如果本Span通过返还之后已经是有freeobj了，将此Span从empty_列表转移到nonempty_列表，如果此Span已经全部空闲了，没有还在被使用的obj，那么通过Static::pageheap()->Delete返还给pageheap。

5、             Pageheap通过Delete函数将返还回来Span的相关参数清零，并设置当前Span为ON_NORMAL_FREELIST。然后判断此Span能不能和前后相邻的Span合并，然后将Span插入相应size的normal队列，最后判断是否需要回收，如果需要，尝试回收至少一个页面，回收动作主要讲Span从normal列表转移到return列表，并调用TCMalloc_SystemRelease将页面标记为可回收的，然后通过系统调用madvise(reinterpret_cast<char*>(new_start), new_end – new_start,                   MADV_DONTNEED)将物理内存返回给系统，而保留虚拟内存。

首席：

系统软件工程师招聘，当然首选弯曲评论打广告，这里汇聚了全球最优秀的系统开发人员，虽然自觉不济，但是我们也是求贤若渴，因此恬不知耻也要发一贴，希望聚集志同道合的人一起玩味系统软件的研发。

嗨，大家好：

君正深圳分公司新建一个系统软件的研发部门，

版权声明：本文转载至2011年10月刊的《计算机世界》报。（作者：冬瓜头（张冬），《大话存储》及《大话存储2》作者，QQ&Email： 122567712@qq.com）

传统外置存储系统或将迎来严酷的冬天

                                                      ——张冬（冬瓜头）

1、存储这十年

    眨眼间，担任存储产品设计规划工作已经一年多了，对存储系统的发展有了一些感触。在2002~2009这7年里，应该说是存储行业在中国落地生根的时期，那时候国内有不少工程师活跃在各种技术论坛，讨论存储系统的基本原理、部署配置等。我记得那段时间内，IBM从LSIOEM过来的FAStT系列的存储系统在国内被广泛使用，技术论坛里基本都是关于这个系列存储系统的讨论。高端存储的讨论则基本聚焦在IBM的Shark系列，当时国内对EMC以及HDS等专业存储公司的产品的关注和探讨明显不如IBM，一个重要原因是因为IBM的存储大量随其服务器捆绑，而EMC和HDS这两家公司当时只有存储产品。再后来就是FAStT的换代产品DS4000系列，再后来就是DS5000，这几代产品均是OEM自LSI，本质上其实就是一个硬件规格不断提升的过程。然而，存储行业就像一个人的成长过程，首先要长身体，但是身体长到一定阶段，就需要长心智了。随着上层业务的多样化发展，底层存储不仅仅再只是一个提供数据存储的盒子，它需要一些灵活易用的数据管理功能来丰富它的价值，比如快照克隆、扩容复制、压缩重删、超供回收以及虚拟化等等。

    在中国，存储从业人员水平也在不断的提高。从这10年期间国内的几个著名存储论坛讨论的课题便可以看出，从当初的一知半解，还在讨论所谓SAN、FC、光纤这三者的概念和区别的阶段，一直到后来讨论起各厂商中高端存储设备的内部架构以及各种数据管理特性原理、实现、价值及应用场景，随后更进一步，讨论起存储系统的选型、部署和规划管理等。我相信随着国内业界对存储的不断认知和积累，首先是厂商与集成商，随后便会是终端客户，随着从业人员水平的提高，终端客户越来越难忽悠，这样就会形成更加专业的气氛和促使国内厂商不断自主研发进取的动力。

十年间，细数存储厂商的变迁。IBM在2008年将早先收购的XIV推向了市场，并且定位在高端存储级别，引起了不小的轰动，这是个里程碑式的事件，它不仅象征着传统高端存储的封闭式架构土崩瓦解，而且还引起了一股Scale-Out热。紧其随后，EMC把经营了多年的传统高端Symmetrix DMX系列的核心软件迁移到了开放式硬件平台上，推出了新一代Scale-Out高端存储系统Symmetrix V-Max；之后一年HDS也按耐不住，将其传统高端存储USP V也迁移到了开放硬件平台，变身成了VSP存储系统，也宣称为Scale-Out架构，但是VSP并不是十分开放，其形态上我认为依然是传统高端的封闭式架构，但是CPU从PowerPC变成了Intel x86，同时保留ASIC芯片，外观上采用大背板，CPU、内存、IO板分离式热插拔，这些依然还是传统高端存储系统的元素。

2011年，EMC将其Celerra产品当做机头，后端挂接Clariion存储，包装成了VNX系列，当然硬件平台是升级之后的。这个产品没有什么本质创新。但是其同时推出了一款低端的VNXe系列，这款产品看似低端，其实暗藏玄机。在笔者在今年3月份的一篇文章《VNXe会给存储系统带来颠覆性变革么》中详细剖析了VNXe内部并且做出推断，存储+虚拟机就是百变金刚。存储+计算，即应用存储很有可能会是后续外置存储系统的发展方向。果不其然，9月份的VMware World大会上，EMC毫无遮拦的表述了这个观点，存储直接运行虚拟机，直接与应用结合，抢占部分服务器市场。（作者：冬瓜头（张冬），《大话存储》及《大话存储2》作者）在应用存储这方面国内某软件公司就颇具前瞻性。

2010年，IBM将其多个产品的多个模块进行了堆叠组合，形成了Storwize V7000中端存储产品，这款产品可以说是IBM真正自研的第一款中端存储系统。EMC在经历了Symmetrix V-Max变革之后，在中端存储系统产品线，也将其CX系列做了终结，换面为VNX系列，后者实则是CX系列升级的硬件版本加上Celerra NAS机头组合而成的一款所谓Scale-Out的统一存储。

就在本月，HP也成功的将收购的3PAR存储硬件升级之后包装为P10000产品型号。

    说道统一存储，不得不说的则是NetApp。作为EMC的头号对手（存储界仅剩的三家专业聚焦存储的巨头为EMC、NetApp、HDS），NetApp是一个老牌存储公司了，上世纪九十年代靠独立NAS起家（取代当时的Linux服务器做NFS共享的方式），本世纪初通过在文件系统上虚拟块空间从而支持了块级访问，并包装为“Unified Storage”概念，广受业界追捧，统一存储的概念一直到现在还没退火。NetApp凭借其强大的增值功能和简便的配置占据了NAS市场老大的位置。从最早期的FAS270、FAS980，到后来的FAS2000、FAS3000和FAS6000，再到后来的FAS3100，一直到最近的FAS3200和FAS6200，NetApp在硬件平台上迁移的很平稳，形态上没有什么大动（除了最近的FASx200系列平台支持IO扩展柜之外）。NetApp的核心竞争力在于其软件，它没有精力去自己搞出类似某公司那样的十几款硬件盒子形态，这样做对它没有任何意义。从其Ontap7.0操作系统开始，支持Flexvol特性，这也是存储业界（作者：冬瓜头（张冬），《大话存储》及《大话存储2》作者）第一个Thin技术的原型，但是Thin这个词好像却并不是NetApp推广出来的。其核心层WAFL文件系统是一个非常强大的角色，号称“The last word in filesystem”的ZFS就是借鉴了WAFL的思想并在多方面进行改良的文件系统，以及变种BTRFS。

    2008年的存储界还有另一件大事，本文笔者的专著，一本里程碑式的著作《大话存储–网络存储系统原理精解与最佳实践》出版了，它是第一本将存储系统基本概念和原理清晰透彻进行表述的存储书籍，在业界引起了广泛好评，让不计其数的初学者快速入了门，为国内存储行业迅速孵化了一大批存储潜在人才。两年后，《大话存储2》也顺利出版了，大话2厚度超过900页，可以说是存储界前所未有之鸿篇巨著，其内容涉及了存储技术的方方面面，甚至在国内学术界也获得了高度评价，并且成功进入了各大院校的专业课程教材体系，同时也成为了各大国内集成商以及存储厂商研发人员手头必备的书籍；同时也受到不少美国硅谷存储界人士的好评。

    然而，看似红红火火的存储市场，即将迎来的可能会是一个严酷的冬天。

2、存储下一个十年

    书接上文。从存储产品形态变化可以看得出来，在硬件形态上，高端存储传统架构崩塌，转为开放式架构，那么存储与服务器架构已经没有本质区别，这一步的变化已经奠定了外置存储系统体系走（作者：冬瓜头（张冬），《大话存储》及《大话存储2》作者）向崩塌的基础。一个事物总是要向前发展，传统双控存储系统在大架构体系上已经没有可以拿得出手的搞头了，所以不得不向Scale-Out架构来发展，就像CPU多核化一样，上百核的CPU都已经可以商用了，那么对于存储系统来说，Scale-Out的下一步又会是什么呢？在没有革命性新技术出来之前，我认为外置存储也就只能这样了，无非就是硬件规格、接口速率的提升过程，激进一些可能直接以磁盘为单位来做Scale-Out，让控制器节点数达到系统内的硬盘数量级，而每个控制器节点规格可以降低，但是这始终还是Scale-Out。

那么我到底想说什么呢？凭什么我认为外置存储系统后续日子会越来越难过？这还得从最近的两个东西说起，一个是固态存储介质，另一个，则是炒得火热的云。

2.1 存储与服务器同质化

上一代存储产品在硬件上还是颇具特色的，尤其是以EMC Symmetrix和HDS USP为代表的高端平台，大背板上安插CPU板、内存板、IO板等。而且上一代高端普遍使用PowerPC处理器。上一代中端产品，到处可觅见ASIC的身影，比如IBM DS4000/DS5000，HDS AMS2000等。而到了这一代，Intel处理器x86硬件平台似乎已经统治了从高端到中端甚至中低端的存储阵列，内部架构与普通x86 PC服务器无异，只是外观以及其他一些专门为硬盘槽位以及维护性考虑的细节上略有不同。只有低端一些产品依然使用ASIC来降低成本。

外置存储发展到这个阶段，已经在硬件上失去了它独立发展的“借口”。其次，在软件上，外置存储的借口也越来越脆弱。随着各种卷管理软件，比如传统的LVM、CLVM甚至GLVM以及Windows平台下的动态卷越做越强，还有Symantec从Veritas继承下来的驰骋多年依然宝刀未老的VxVM以及Storage Foundation平台，再加上号称“The last word in filesystem”的ZFS以及其变种Btrfs，甚至原Sun公司的统一的存储软件ComStar等平台，这些角色的发展对于传统外置存储的软件层来讲，都是威胁。比如ZFS，容错保护、数据校验纠错、快照、Thin、Dedup、Clone、Replication等外置存储用来增值的特性，它也都已经集成了，只要将其架设到JBOD或者服务器自带存储介质上即可形成一个差不多的存储系统，既可以用作自身使用，也可以通过SCSI Target向外部提供存储空间成为一个独立的存储设备。

2.2 固态存储介质终将一统

固态存储介质的好处就不必多讲了，想必大家都很了解。固态存储介质迟早会取代机械磁盘，这也是大势所趋，虽然短期内不太可能，但是不排除若干年之后不会发生。固态存储介质的可靠性、容量、存储密度以及成本均会越来越变得让人容易接受。机械磁盘届时已经没有必要存在，而磁带可能相对于机械磁盘稍晚些一样会被固态存储介质所替代。Flash硅片也有不同的规格等级，使用低规格大容量的Flash阵列完全可以提供比传统物理带库或者VTL更划算的备份介质。这样，从RAM到归档设备一条路下来就不会有任何机械部件存在，而且性能和成本可以是平滑下降的。

我曾经在某客户机房看到过某公司高端存储产品，占用了整整一个机柜的空间，风扇呼呼的吹着，噪音让人头疼，结果上面只插了几十块甚至十几块磁盘。这其中其他原因暂且不提，你懂的。咱们抛开其他因素，从任何方面讲，这都属于投资浪费。这几十块机械硬盘在高端存储上所能提供的性能，可能只需要几块SSD就可以满足了。至于容量方面，目前很多场景容量都是过剩的，由于机械盘无法提供太高IOPS，不得不用几十块甚至上百或者数百上千块磁盘来堆出所需要的性能，然而磁盘容量的增长速度远比性能增长速度快，那么数百块600GB的磁盘，就可以达到上百TB 的空间，而这些空间绝大多数可能都被浪费了，只因为单个机械盘性能不够。机械盘拿数量来换性能，容量过剩。；而SSD则是性能过剩而容量稍小而且价格太高。但是容量和寿命问题可以随着技术发展不断得到解决，价格也会不断降低，而且如果从耗电、占地等个方面综合判断，SSD的$/IOPS显然是划算的。

2.2.1 历史车轮不可阻挡

外置存储控制器的前世形态其实是插在服务器里面的Raid卡，后来为何会扩充出去独立成为“存储系统”？多种因素，性能和空间问题为主要，另外一种因素是用于多主机共享存储，后面这个因素目前看来，有点鸡肋，到底有多少主机需要与其他主机共享空间？他们只是在“共享同一个设备”，真正需要共享空间的有两种情况，一种是特殊应用，比如视频领域、Web Server集群、HPC集群等等，而这些场景毕竟有限；其次则是最近几年Thin Provision炒作起来之后，确实可以做到全局空间动态分配回收，但是又有多少人真正用到？从这一点上看，这个因素确实是个鸡肋，不会阻止底层技术车轮发展导致的上层形态的变革。所以，共享同一个设备，或者共享同一个空间，只是为技术的发展所创造的一个噱头。而我相信当存储形态重新轮回回来之后，又会有新噱头被创造出来。

所谓“轮回回来”具体是指什么呢？由于固态存储介质成本的不断下降，性能和容量的不断提升，体积的不断降低，在一台服务器中集成高密度、大容量、超高性能的的Flash介质无疑还是最方便的存储形态。想想看，你不再需要购买什么FC HBA、SAS HBA、Infiniband HBA，也不需要理会什么iSCSI、FC、SAS协议，部署时也不需要连接一大批线缆，更不需要购置什么所谓“存储交换机”了。所以，导致当年Raid卡进化为外置控制器的第一个问题，也就是服务器空间、容量和性能的问题，就这么轻易被Flash固态介质解决了，非常彻底，决不拖泥带水。至于第二个问题，也就是数据共享访问的问题，上文也说了，场景有限，有点鸡肋。但是如果确实需要共享访问了怎么办呢？也好办，外部网路带宽是飞速发展的，多个独立服务器节点完全可以通过外部网络来将各自的存储介质通过某种分布式卷管理系统或者分布式文件系统联合起来形成一个大共享存储池，这些技术已经比较成熟，尤其是云架构炒作起来之后，这些在技术上根本不是问题。所谓轮回，就是指外置存储控制器最终在出来溜达了一圈之后，遇上了Flash挡道，最终又不得不乖乖投胎为其前世Raid卡，回服务器机箱里呆着，这就是历史的规律。

最近也遇到了几个企业IT管理员问了一些问题，大致是“我到底为什么要使用SAN”，如果换了几年前，我或许直接会这么回答：“SAN可以消除孤岛，数据共享”等等等等，但是现在，我不会再拿着这些当初被忽悠的词句去误导别人了，至少回答之前要问清楚他目前的业务类型、数据量以及后续需求等。其中有一个人我确实没有推荐其使用SAN，因为他的业务完全本地盘就已经满足需求，况且还是使用PC服务器，如果使用小机等扩展性更强的服务器，一台机器上完全可以扩充到几十甚至上百块硬盘，对于一般通常业务来讲，有什么理由去拉根线连到外面存储上取数据呢？

有人会问，数据如果不集中存放的话，备份怎么办呢？还可以集中备份和LAN-Free么？这个问题，如果熟知现在的备份数据流就根本无需担心。当前来讲，就算是所谓“LAN-Free”也一样需要数据先从SAN阵列中读出到主机，然后再从主机写到备份介质。笔者另一篇文章《乱七八糟的“Free”》中对这些名词有详细的解释。而对于DAS模式下的备份，数据只是从每个服务器本地盘读出来然后写到备份介质中，与SAN备份没有本质区别，甚至速度可以比SAN备份更快。至于所谓“集中备份”，除非使用NDMP设备到设备直接备份模式，那么这个“集中备份”也没有意义，现在数据先从主机读出再写到备份介质依然是主流的备份方式，这与DAS下的备份数据流没有区别。

在来看看DAS模式下的容灾。在SAN模式下，直接通过两地的阵列做集中的数据远程复制与接收，确实比DAS模式下每个节点单独做复制要方便的多，这一点确实算是一个劣势。但是回头想想，如果这些节点是处于云中的，由两个云之间来做容灾，那么又会被统一起来。而且目前来讲仍有非常大比例的系统采用的是基于应用层的数据复制，而不是底层存储层，比如Oracle DataGuard、DB2的HADR等等，这类复制能够保证数据一致性并且可回放，底层存储有时候并不能完全信任，10次有2次会产生应用无法启动的数据不一致。

另外，SAN的另一个噱头，即“集中管理”。如果整个数据中心只有少数几台集中存储设备，那管理起来确实比较方便，尤其是对一个尚没有完善的自动化运维体系的数据中心来讲。在配置存储空间的时候，如果有一套比较好的管理软件，那么在一个全DAS环境中配置起来也不见得要比配置集中存储来得复杂。但对于后期维护操作，全DAS存储环境确实会增加不少复杂度，这就需要一套完善的自动化运维工具和体系来应对这个问题。

至于各种外置存储所提供的快照、重删、Thin等数据管理特性，（作者：冬瓜头（张冬），《大话存储》及《大话存储2》作者）随着芯片性能不断提升，Raid卡上直接集成这些功能，也将不再是难事。

总之，上述的种种因素，最终都会将目前的传统外置存储系统逼上绝路。

2.2.2 存储厂商面对Flash，友善还是敌对？

既然上文中我把Flash看做传统存储的死敌，那么目前一些存储厂商对Flash是什么态度呢？最早痛恨Flash的专业存储厂商是NetApp。在笔者的另一篇文章《引领潮流、随波逐流、最后追赶潮流？——在荆棘中挣扎前进的NetApp》中曾经就WAFL与Flash之间的恩怨做过分析。但是不知道当初NetApp反对Flash是不是也有更深一层的担忧，即Flash或将革掉自己的命。但是大势不可挡，如今所有主流存储厂商都针对固态介质做了处理，比如各种动态分级或者缓存技术。NetApp的PAM加速卡就是一张插在其FAS阵列中的PCIE Flash卡，其被用作WAFL文件系统的缓存，而不是直接承载WAFL主体数据。NetApp也曾经说过将来存储系统中只有两种介质——SSD+SATA，但至少目前看来，NetApp最新的FAS阵列依然是支持SAS与FC磁盘。

EMC对待固态介质的态度一向都是积极的，他知道固态介质势不可挡，逃避是没有用的。也曾经大有信心的说SSD将取代FC盘，并且从FAST1.0到FAST2.0再到FAST VP，一直不遗余力的让SSD在阵列上发挥最大价值。其他厂商则基本都是追随者，随大流，针对SSD也都是不遗余力的支持，包括开发动态数据分级/缓存方案，以及在内核中针对Flash介质特有的IO特性做各方面优化。

FusionIO，一家专做PCIE Flash卡的尖兵厂商，在互联网后端这个细分市场占据了不少市场份额。互联网企业IT系统的前端和后端是当今最流行IT技术的发源地，从这里也可以对后续IT领域的发展趋势掠探一二。FusionIO的卡，说俗了就是一种DAS（Direct Attached Storage）方式，你能说它相对于SAN方式是一种倒退么？肯定不是，与其说是倒退，不如说是轮回。能在服务器本地满足的IO性能，何必去花大价钱买个高端存储而且性能还不够呢？国内某互联网公司几乎明确了他们的观点，即去IOE，也就是IBM的小机、Oracle的RDBMS以及EMC的高端存储。从这一点上来看，EMC已经被FusionIO抢了不知道多少单出货高端存储的机会。

EMC能不有所动么？这不，EMC发布了所谓“闪电计划”，也开始搞插在服务器上的PCIE Flash卡作为阵列的前置缓存，然而他肯定不能以后就卖卡为主了，他真正想带动的还是其阵列，所以“闪电计划”的最终目的其实是EMC想通过服务器主机端的PCIE卡产生一个链带，后端还是要购买EMC的存储阵列，所以闪电计划在互联网后端肯定是不被买账的，EMC这段时间好像对互联网后端额外重视，但是眼巴巴看着金子被别人挖走，心有不甘。收购GreenPlum就是一步棋。就好像看着一座金山，拼命往上爬却发现脚底打滑，于是就去鞋店大肆采购各种鞋子。

PCIE Flash是所有传统存储厂商的对手，虽然有厂商比如NetApp将PCIE Flash卡用到自己阵列里给自己加速，但是敌人永远是敌人。

固态存储介质让传统外置存储难受其实还有另外一个原因。传统外置存储控制器一般为每台设备双控制器，这台设备后端如果挂太多SSD，由于固态介质响应时间和IOPS“过高”，则会无法发挥出这些ssd的性能，可能在20块左右就可以饱和一台中端存储的性能。如果后续SSD真的全面取代机械盘，那么外置存储控制器就会成为大瓶颈，陷入不利环境。从这一点上来看，传统外置存储走向Scale-Out分布式，增加CPU/RAM与盘数的比例，是支撑全SSD的一个必要条件。

2.2.3  VTL已经成为备份软件厂商的傀儡

VTL也算是一种外置存储系统。VTL这个东西已经赖乎乎的存在了很长时间了，其幕后始作俑者其实就是一些主流的备份软件厂商。这些垄断厂商在操控各种物理带库、磁带机的磁带和机械手方面拥有大量积累，一般厂商较难掌握，所以这套接口宁愿保留，哪怕介质从磁带换成了硬盘，操控和数据接口也要保留。对物理带库体系的操控、对上层应用的数据接口以及备份之后数据的生命周期管理，这三大件就是这些厂商的生存根基，他们不想失去任何一个。

仅有少数的愿意创新的新型备份软件厂商或者初创不久的厂商才会去推广纯D2D备份，更加专注于上层的数据备份与恢复管理，探索创新。这些厂商在物理带库、机械手等方面基本没有积累，（作者：冬瓜头（张冬），《大话存储》及《大话存储2》作者）那么他们就是让VTL彻底退位的人。而随着存储厂商越来越看清市场，在数据保护方面发力的厂商会越来越多，传统体系下的壁垒一定要被冲垮。

而后续低规格大容量的Flash作为备份介质是必经之路，如果那时候的数据和操控接口依然沿用传统物理带库的SCSI流式指令以及机械手控制指令，就非常说不过去了。Flash是可以随机寻址的，控制Flash选择和读写的是片选器（Chip Enabler）以及ASIC芯片，都是电子器件，何来机械手？任何方面都说不过去。

VTL接口被替代之后，下一步就需要数据记录格式的替代，让备份之后的数据直接可以看到，直接可以从备份介质中恢复到源端，而不是使用物理磁带的格式去读写和存放。

所以，传统物理磁带以及VTL备份介质体系也即将走向终结。

2.3 云计算架构最终会将存储“埋起来”

既然传统存储盒子或将枯萎，那么是否可以做点高层的脱离盒子的东西，比如虚拟化，数据迁移等数据管理方面的“智能一些的盒子”或者方案呢？很不幸的是，这条路可能也将会被堵了。

2.3.1 阵列能做的，云几乎都能做

什么是云存储或者存储云？我是这么定义的，传统外置存储就是用几个控制器来挂起后端的磁盘扩展柜，然后对外提供存储空间；而存储云就是用一堆服务器上面跑的软件当做控制器，挂起后端一堆异构厂商的各种存储介质包括JOBD、双控或者多控阵列、NAS、VTL、带库等等并向外提供各种不同访问方式的存储空间。（作者：冬瓜头（张冬），《大话存储》及《大话存储2》作者）服务器集群上跑什么软件？当然是某种分布式卷或/和者分布式文件系统，这种系统具有原生的异构支持，不管底层使用谁家的阵列，都可以被收纳为存储资源。当然，像传统阵列一样，仅仅有了存储空间就够了么？存储云当然还需要做各种数据管理功能，比如容错、快照、Thin、重删、动态分级、克隆、迁移、远程复制、容灾等等。这些特性，在一个分布式文件系统或者卷管理系统上是完全可以做的，但是一些比较耗费计算资源的比如重删，则可以下放给底层设备来做。云为何不信任，或者说不能够信任底层设备上原配的这些功能呢？答案很简单，就是异构支持。存储云中总不可能只有一家设备厂商的设备，而不同厂商的设备之间的这些特性又是不兼容的，所以只有在上面的虚拟化层，也就是分布式数据管理层来处理这些特性，此时，外置存储系统就是彻彻底底的一块大硬盘，不管你是EMC Symmetrix还是HDS VSP/USP，还是JOBD，甚至或者是服务器本地磁盘，是否是Scale-Out架构甚至都已经没有意义，因为上层的虚拟化层自己可以Scale-Out。对于云来讲，或许只有磁盘有意义，其他比如JBOD、控制器、Scale-Out架构之类，云统统不在乎。

2.3.2 观VMware动作，体会后续趋势

当年EMC收购VMware，谁也不曾想到VMware会有今天的市值。如今VMware已经是云架构中的核心角色。既然已经成为核心，那么就有权利发布一系列接口让别人来适配他。从第一个比较系统的VAAI，到第二个VASA，再到将来会发布的第三代API。

在第一代VAAI中，VMware只是将一些原本由Hypervisor做的数据操作工作下放给了外部存储系统来做，提高效率，从其全名vStorage APIs for Array Integration就可以隐隐领会出VMware还是比较看重外置存储的，能够将重要任务交给它们。

而在第二代VASA（vStorage APIs for Storage Awareness）中，显然可以领会到VMware进一步控制外部存储的欲望，VMware需要了解到更多的外部存储的信息。做过底层存储开发的都知道，硬盘驱动程序会探知控制器后面所挂的硬盘的各种信息，包括容量、是否支持WriteBack模式缓存及具体类型、是否支持队列、最大传输单元等等。而VMware这套VASA接口分明就是做了硬盘驱动的工作，以便后续更好的对外置存储进行控制。（作者：冬瓜头（张冬），《大话存储》及《大话存储2》作者）显然，外置存储对于VMware，就相当于一块大硬盘。

而就在今年的VMworld大会上，VMware的动作已经显露无疑，VMware计划将vSphere环境中的存储管理和精简配置进行“根本性的”改变，无需再设置LUN、RAID组合NAS挂载点，VMware工程师Satyam Vaghani称新版API将使用工具如I/O Demultiplexer、Capacity Pool以及VM Volume。对于这第三代存储API的细节尚不知，但是从字面来看，第三代API将会对外部存储实现彻底的大统一，任何存储厂商在VSphere下都被同质化，谁也别想冒出来，那些传统的特性对于VMware存储虚拟层来讲，都是小儿科。

各厂商新产品的宣传噱头上，除了硬件规格之外（其实硬件规格大家都差不多），就是对固态存储介质的应用方案，再就是与云搭上边，也就是Thin以及VMware API支持。

综上，外置存储系统在经历了从服务器内置到外部独立控制器的进化过程之后，在虚拟服务器的召唤之下，其地位又回到了原点。

3、外置存储后续的生存和发展空间

这场残酷的严冬，对于国内外置存储厂商来讲，将会是一个异常难熬的过程。而那些专注于硬件上层功能、方案的存储厂商不会受到太大影响。比如备份容灾等，不管底层采用什么介质、什么架构，用户对备份和容灾的投入将是持续的。而且当机械操控协议彻底被废止，也就是VTL真正被淘汰之后，备份软件厂商就会更加专注于数据的管理，而且门槛会降低很多，会催生更多竞争者进入，而不再是几家在机械操控协议和兼容性方面有多年积累的厂商把着那千年陈糠来垄断市场。当然，这些厂商不能只在备份容灾方面发展，“存储”这个词不仅仅是硬件盒子+备份容灾，比如还有数据管理、应用存储优化等等

做盒子的传统外置存储厂商怎么办？这类厂商生存在IT生态链最底层，铺开大摊子，拼规格，拼价格拼量，备货、物流、维护，好不热闹，可是这一层却是利润最低的。而现在他们的死敌固态存储介质正在茁壮成长，IT大架构也在向着云方面发展，他们只能望洋兴叹。

传统存储厂商转型迫在眉睫，尤其是那些专注于生产存储产品的厂商，要么做成全球最大的存储盒子加工厂，以量取胜，要么就往上走，让存储设备直接体现业务价值，而要往生态链高层迁徙的话，就必须脱离做盒子的老思想，盒子里面有什么东西能解决用户什么问题，才是最重要的。

而如果想傍着云来做些东西的话，存储+云就是所谓“云存储”？“云存储”其实并不存在，任何形式的存储都是云存储，包括单块硬盘。存在的只有存储云。前者是依然想以存储为中心，而这可以说是逆势而为。而存储云则是以云为中心，也就是以将任何形式的异构存储空间整合利用的云虚拟化层为中心。如果对这一点理解存在偏差，认为做云存储就是去做一款新形态的分布式存储硬件，那基本上还是走老路。

但是如果去做存储云，也就是专注于虚拟化整合，那么这与存储硬件就基本脱离关系了，而完全转向了数据中心管理软件，或者说通俗点，网管领域，或者说的专业点，自动化运维领域。

最后，不得不说一下赛门铁克。其实是赛门铁克所收购的Veritas的Storage Foundation（SF）产品，这东西真的是个很好的胚子，他可以适配任何异构存储，将底层存储空间虚拟化成大的统一存储池。但是SF貌似生错了年代，太超前了。当云架构有这个诉求的时候，机会就摆在眼前了。赛门铁克已经拥有了多厂商支持的平台，（作者：冬瓜头（张冬），《大话存储》及《大话存储2》作者）那么对于他们来讲，开发一个用于云底层的大统一的存储基础架构从而为各种虚拟机Hypervisor提供底层资源是水到渠成的事情，我们就静观其变吧。

小结

后方被固态存储介质追杀，前方则遭遇云架构的围堵，传统外置存储，将会走向非常窄的道路，需要外置存储的场景将会仅限在少数行业的少数系统中，仅有少数厂商挣扎存活，偃旗息鼓，然后漫长的等待着新技术新革命时代的到来。更有甚者，单纯存储厂商或被IT巨鳄们收购也不是没可能。

而我们这批所谓“做存储的”，出路在何方？看来我还是回家呆着继续大话存储误人子弟吧。

轧空和乐观情绪在上周蔓延。前期市场被大规模做空之后，市场迎来了最近上涨最为迅猛的一周。从周一开始，由于上上个周末的德法会谈，表示要重塑银行业，市场就开始上涨。涨势一直持续，标普从一度跌落到1075点到回升至1224点只用了一周的时间。
这轮上涨是否就是牛熊转换的开始，目前还值得怀疑和观察。原因有以下几点：
第一， 现在的上涨，多是由于对于欧洲债务危机解决的乐观推测所导致。而欧洲债务危机解决方案的具体措施和细节还没有公布，内部是否还有困难和矛盾仍然有待观察。解决这个危机，需要大量的银子，这些银子从欧洲节衣缩食的纳税人那里获得？还是投资人承担？或者是透过其它国家借贷？这些问题并没有形成最后答案。
第二， 希腊仍然可能违约，意大利和西班牙也接连被降级，若干大银行被列入待观察名单。评级机构的一系列动作表明问题还没有得到有效解决。
第三，目前的经济数据虽然有所好转，不至坠入衰退的情形，但是就业形势还不足以消除高
失业率。四周平均申领失业救济人数仍然在400K以上。建筑业没有改善。
第四，市场的上涨虽然很猛烈和强劲，但是成交量和平时的突破相比，明显不是很巨大。成
交量是衡量突破的一个重要指标，买气不足，也许是投资人还在观望。一旦形成大成交量的持续上涨，市场的情绪就真正地变化了。

周一欧洲市场持续上涨，突破前一波上涨的高点。乐观情绪让投资者看到了希望，只要欧洲的政治家认真计划和解决这个事情，市场相信情况会逐渐好转起来。美国市场现在是随着欧洲市场的走势，只要欧洲市场上涨，美国市场也跟着前进。最近奥巴马的就业刺激计划未获通过，也变得不是很受关注。美国自身的大笔外债以及债务削减计划仍然是个悬而未决的问题。但是乐观和期望，加上前期市场大量卖空，无缘由地市场就会向上前进。只要有信心支持，似乎经济数据的好坏已经不那么重要。
不过，市场会回归到根据实际经济情况来决定市场走势的状态。最终还要靠经济发展的情况和各大公司的赢利来推动市场的前进。

尊敬的陈首席和各位弯友，

江湖传言这里藏龙卧虎，聚集了大批网络、安全和存储等领域人才。联创信安特借宝地发布存储研发职位信息，诚邀有志存储研发之士加盟。

职位名称：(高级)存储软件研发工程师
工作职责：从事存储系统软件的研发工作
1. 参与存储系统软件的架构与设计;
2. 负责该系统的编码实现、调试与性能优化;
3. 负责技术难点攻关与课题研究;
4. 存储新技术研究与产品预研；

职位要求：
1. 熟悉Linux系统管理，至少熟悉一种脚本程序设计语言，如Shell、Perl、Python;
2. 具有Linux C/C++开发经验，熟练掌握和运用常用的数据结构与算法;
3. 熟悉Linux系统下网络编程、多进程/多线程编程、进程间通信技术;
4. 具有网络存储、分布式存储、分布式文件系统等相关研究与开发经验者优先;
5. 熟悉Linux内核及有开源项目经验者优先；

联系方式：zhaopin@udsafe.com.cn

公司简介
北京联创信安科技有限公司（中英文简称：联创信安/UDsafe）是国内领先的信息安全应用系统供应商，致力于为客户提供高品质的全线存储产品和行业解决方案。
秉承“融合应用，持续创新”的核心经营理念，多年来，联创信安深刻理解中国客户的存储环境与需求，运用全球最新技术，为客户构建适用存储解决方案，实现客户最佳投资回报率；联创信安长期在技术创新领域增加投入，不断推出新技术、新产品帮助客户提高商业竞争能力。联创信安累计获得数十项计算机软件著作权登记证书及专利发明。联创信安成功推出的实时备份与快速恢复系统（SDOP）、容错存储系统（RSS）、海量集群NAS系统（PanaStor）等具备业界领先性的解决方案已广泛应用到各领域，并产生了深远的影响。

更多信息请访问公司网站 http://www.udsafe.com.cn

研发中心简介
研发中心是公司新筹建的部门，是公司规划的未来战略核心团队。
我们的愿景是打造具备核心技术竞争力的世界一流存储软件研发中心。
我们的使命是构建完全自主产权和创新的存储产品体系，持续研究存储新技术，引领存储行业产品和技术发展趋势。
目前我们的研发方向是集群存储、云存储、虚拟化存储平台等，未来技术规划包括高效智能化存储平台和云存储基础架构等。

加入我们的优势
(1)我们是专业的存储厂商，存储行业正处于浪潮之巅，公司目前处于高速发展阶段，这是一个有志于存人士的创业平台；
(2)这是一个崭新的团队，研发中心正在筹建初期，目前是一个绝佳的加盟时机，发展空间很大，并有机会与公司一起发展壮大；
(3)公司高管和研发中心负责人均具有多年存储行业从业经验，从产品、市场、营销到研发，与我们一起作将加速你的成长；
(4)我们的研发方向与存储技术热点与发展趋势一致，在这里你将与我们一道打造引领存储行业发展的创新产品；