Chinaunix

标题: Linux存储大家谈！ [打印本页]
作者: send_linux    时间: 2011-11-30 16:23
标题: Linux存储大家谈！
对于系统运维人员来说，Linux除了桌面系统，在计算机操作系统中逐渐占据了重要的市场份额，随之而来的是Linux在各种平台上的存储问题，大到超级计算机处理数以pt级的数据，小到各种工控设备处理各种微型的存储设备，您在Linux平台下遇到过何文件系统的问题，如何解决，有什么好的想法？

同样对于开发人员来说，大多数爱好者在阅读Linux内核源代码时会产生这样的困惑，我们很少能找到针对Linux操作系统，甚至是某个单独的内核模块，在设计和开发方面的文档。仅有Linux社区的一些高手们对一些关键算法或者一些设计考虑的讨论。此外，当前大多数的源码分析书籍，都只是就函数或代码进行解释，没有给出整体和全面的视角。对于处于新手上路，或者小技初成级别的读者，只能获得获得局部和片面的认识，在理解这些讨论和阅读内核源码时会非常困难，常常产生挫败感。

欢迎大家参与本期的技术话题讨论----Linux存储大家谈！

讨论话题：
Linux系统下的存储解决方案
Linux内核中的存储设计原理
嵌入式Linux系统设计中存储注意细节
...........
...........

只要和Linux存储相关的，都欢迎加入我们的讨论！

活动嘉宾：
敖青云博士，CU论坛ID为ao_qy，《存储技术原理分析:基于Linux 2.6内核源代码》一书作者，2001年毕业于上海交通大学计算机科学及工程系。毕业后一直从事存储及相关产品的研发工作，主要研究方向为开源技术、操作系统、存储及虚拟机技术等。
happy_fish100，CU论坛开源项目FastDFS版块版主，FastDFS文件系统设计者。
T-Bagwell，CU论坛嵌入式开发版资深版主，嵌入式linux文件系统爱好者。

本期图书赞助：电子工业出版社《存储技术原理分析:基于Linux 2.6内核源代码》

活动时间：2011年12月1日——2011年12月24日


活动奖品：
挑选最佳讨论会员两名，各奖励CU十周年纪念背包一个
挑选优秀讨论参与会员5名，奖励《存储技术原理分析:基于Linux 2.6内核源代码》一本
----------------------------------------------------------------------------------------------
存储技术原理分析：基于Linux 2.6内核源代码

作　　者敖青云
出 版 社电子工业出版社
图书定价￥118.00

图书简介:
《存储技术原理分析(基于Linux2.6内核源代码)》(作者敖青云)通过对 Linux 2．6内核源代码的分析，详细讨论存储技术的内在实现原理。分为三条主线：解释PCI设备、SCSI设备及块设备的发现过程；跟踪存储I／O路径，即用户对文件的读／写请求怎么通过中间各个层次，最终到达磁盘介质；此外，还简要介绍主机适配器、块设备驱动及文件系统等编程框架。
     《存储技术原理分析(基于Linux2.6内核源代码)》中将设计一些主要的场景，跟踪实现的各个层次，对其中的主要函数进行代码级的讲解。在分析每个模块时，会给出整体框架与主要数据结构之间的关系，并列出各个域的详细含义。
     采用这种方式，希望读者能对存储相关概念(如RAID、快照等)的内在实现有具体的了解，也试图帮助读者理解Linux内核设计和开发的一些思想，为进一步分析其他模块(如进程管理、内存管理等)起借鉴作用。
     本书适合作为高校计算机相关专业本科生和研究生学习操作系统的辅助和实践教材，也适合作为Linux爱好者学习内核的参考书籍。同时，它也是存储从业工程师深入理解存储架构，以及软件开发工程师掌握软件架构的有效工具。
作者: happy_fish100    时间: 2011-11-30 16:59
回复 1# send_linux

我了解的情况，文件系统ZFS用得还蛮多的。
ZFS在freeBSD下运行良好，在Linux下支持得不是太好。
作者: cu_little_bird    时间: 2011-11-30 19:48
回复  send_linux

我了解的情况，文件系统ZFS用得还蛮多的。
ZFS在freeBSD下运行良好，在Linux下支持得 ...
happy_fish100 发表于 2011-11-30 16:59



    Symantec的VxFS很强大，支持主流服务器系统（AIX, HP-UX, solaris， suse/redhat）。而且对主流阵列的兼容认证。
作者: ao_qy    时间: 2011-12-01 09:32
抛开商业系统不谈，开源社区中就有很多非常优秀的项目，ZFS无疑是其中的佼佼者。由于版权的不兼容性，暂时还无法集成到Linux内核，确实是一个遗憾。个人希望国内的有志之士能将这些项目进行深入剖析，整理成章节以飨读者，相信可以提高国内在Linux存储方面的整体的、基础的水平。从短期来讲，国内的技术创新能力还是有限。但是，从模仿能力和应用能力方面，我们还是有实力的。
作者: send_linux    时间: 2011-12-01 09:33
抛开商业系统不谈，开源社区中就有很多非常优秀的项目，ZFS无疑是其中的佼佼者。由于版权的不兼容性，暂时还 ...
ao_qy 发表于 2011-12-01 09:32



   谢谢作者的热心解答：）
作者: chenyx    时间: 2011-12-01 09:55
开源的存储软件,我测试过的有freenas和openfile,感觉都不错.
作者: chenyx    时间: 2011-12-01 09:56
linux的下一代fs,brtfs不知道什么时候release啊,应该和zfs有一拼
作者: happy_fish100    时间: 2011-12-01 11:15
FastDFS是一款开源的应用级分布式文件系统，为互联网企业量身定做，其特点可以概括为：简单、高效、灵活！
有感兴趣的朋友可以到FastDFS论坛中逛逛：http://bbs.chinaunix.net/forum-240-1.html
作者: king_819    时间: 2011-12-01 11:40
本帖最后由 king_819 于 2011-12-01 11:43 编辑
FastDFS是一款开源的应用级分布式文件系统，为互联网企业量身定做，其特点可以概括为：简单、高效、灵活！
...
happy_fish100 发表于 2011-12-01 11:15



   FastDFS 只能通过API使用，不支持fuse，不过在处理海量图片的时候性能不错，比mogileFS性能更好
作者: king_819    时间: 2011-12-01 11:51
最近讨论的比较多的就数mooseFS了，mooseFS到是支持FUSE，相对比较轻量级，对master服务器有单点依赖，虽然有人通过DRBD+Heartbeat解决了单点问题，但master服务器还是存在性能瓶颈，就是mysql主从同步一样，从可以扩展，主却不容易扩展，mooseFS把文件系统的结构缓存到master的内存当中的，文件越多，内存消耗就越大
作者: king_819    时间: 2011-12-01 11:55
服务器不多，数据量不大的情况下，NFS还是不错的
作者: jerryjzm    时间: 2011-12-01 13:40
说到zfs，感觉这个设计理念本身就很好，oracle在其数据库方面使用asm，也有很多理念上的相似。
作者: waily    时间: 2011-12-02 09:33
悲剧，我只知道ocfs2
作者: milujite    时间: 2011-12-02 09:38
本帖最后由 milujite 于 2011-12-02 10:04 编辑

首先ZFS，LINUS大神估计做梦都羡慕BSD，能用到优秀的ZFS。从现在大集中的趋势来看，存储集中管理是很必要的，ZFS的特点很明显，所有的磁盘在ZFS里都只是存储池的一部分，非常适合存储集中管理的环境。按需分配提高了存储空间的利用率，在海量文件情况下，ZFS明显比线性的INODE-TABLE在查找文件方面更加迅速，事务日志也是ZFS的一大特点，保证了数据一致性，同时ZFS还集成快照、镜像、raid等技术。同时BTRFS也是由ORACLE主持的文件系统，其设计和ZFS类似，并且针对SSD写均匀分布做了优化，支持存储区、段管理等。目前BTRFS已经进入了FEDORA和OPENSUSE发行版，在安装时候可选择使用，从这两者在Linux企业发行版的试验田地位来看，BTRFS进入RHEL和SLES也不远了。（ORACLE真是幸福的公司，同时拥有ZFS和BTRFS）。

NFS，NFS还是Linux文件级共享的首选，配合autofs等服务，NFS快捷方便，即插即用。

Linux分布式文件系统，Linux分布式文件系统很多，在本论坛，主要讨论的是Mooefs、LUSTRE等等，与NFS相比，分布式文件系统更适合海量文件的大规模共享和并发访问，这些文件系统一般meta和trunk分离，并且有多个meta和trunk服务器，能够避免单点故障，但是文件过多可能导致meta服务器对内存要求很高，因为这些meta信息需要存放在内存里被快速访问。

Linux在存储方面目前碰到的最大问题还是在线对SCSI的识别上，虽然官方有给出方法，但是要让普通管理员去明确确定存储的cxtxdx和LUN号还是相当有难度的吧。

在故障方面，Linux最多碰到的问题应该就是文件系统ro和磁盘故障吧，ro很好处理，umount和fsck可以解决，磁盘故障就只能更换磁盘了。
作者: ao_qy    时间: 2011-12-02 09:41
《存储技术原理分析——基于Linux2.6内核源代码》网上试读链接：
http://www.china-pub.com/computers/common/mianfeisd.asp?id=198593（互动）
http://www.amazon.cn/gp/reader/B ... b_dp_pt#reader-link（卓越）
对于书中内容，若有疑问，可在此提出，本人愿尽力解答。
作者: milujite    时间: 2011-12-02 09:58
悲剧，我只知道ocfs2
waily 发表于 2011-12-02 09:33



    ocfs2如果实验搞RAC之类的还行，在生产环境，感觉还是别用这个。不是说OCFS2不好，而是在生产环境中使用，出现问题，可用的支持太少了。上个月刚帮客户布了一个ocfs2+rac（客户要求OCFS2么办法），部署完成后，一切正常，只是重启了下，一节点莫名其妙怎么都挂不上，提示BUSY，但是看日志，真没什么可诊断的信息，除了该死的提示网络问题（反而误导了我故障诊断），文档也少的可怜，官方那篇文档在troubleshooting方面真没啥参考价值。第二天，无意打开OCFS2-console，随便点了下mount，莫名其妙的就挂在上了，用mount看了下文件系统挂载情况，ocfs2-console用设备路径挂的磁盘。我是用LABEL挂的，在没重启前都正常啊，想用LABEL去挂还不是为了不让multipath变化时不至于导致挂载失败，最后试了LABEL和UUID挂载，怎么都挂不上，只好去绑定mpath和wwid，然后用设备路径去挂载。
作者: deadwind    时间: 2011-12-02 10:45
本帖最后由 deadwind 于 2011-12-02 14:08 编辑

日常运维中，发现几个存储方面问题Linux还做得不好，主要有：

1.Unix操作系统在线识别存储的功能很强大，几乎95%的情况下都能正常识别不用重启，而Linux较难实现，虽然有一些小方法或HBA卡厂商的一些脚本，但也不怎么靠谱，不知道Linux啥时候能把这个功能做到Unix水平，可以说这是日常运维中一个很重要的方面，对Linux提升到企业级操作系统很有意义；

2.没正常umount NFS文件系统的Linux主机发生网络故障而NFS server又取消这种情况时，会发生无法通过df查看文件系统，查看即假死，此时无法正常umount NFS和强制umount NFS，可通过重新搭建和原来相同的NFS server提供服务才能解决；

3.存储设备管理监控方面还是太多，比Aix、Solaris差的还远，虽然没有第1项在线识别存储那么重要，但也不方便日常管理维护；

对Linux在存储方面的展望，主要有：

1.早点儿支持pNFS；
2.支持ZFS；
3.btffs早点儿搞出来用到企业级；
4.啥时候能搞出个比samba更好的企业级CIFS server来，可以不用买专业NAS了(当然这个要看MS愿不愿意开放了)；
作者: storm the front    时间: 2011-12-02 10:57
分布式文件系统还有一种是metadata和trunk不分离的，没有明确的MDC，比如被红帽收购的glusterFS和被hp收购的ibrix，这样的好处是在处理大量的小文件时，所有的trunk服务器可以平均分摊巨大的元数据压力。在小文件的读写上要比lustre,stornext这类的结构更有优势
作者: yuanbor    时间: 2011-12-02 11:56
Linux存储难道只是文件系统？
没有IPSAN、FC SAN、IB SAN？
没有数据压缩、重复数据删除、自动精简配置、自动分层存储、存储虚拟化？
没有双控制器、缓存管理？
作者: crazyhadoop    时间: 2011-12-02 13:02
最近借机会研读了一下文件系统，恰好有点研究。

我触手可及的文件系统 有2种， 一种是底层内核系统级别的，比如ext4，ceph，这是两种个人目前感觉比较有前景的，另外一种是应用层级别的，类似数据库的存储，鉴于目前互联网业务的发展，各类数据存储系统层出不穷。有些是为了能适应业务的发展要求定制的。比如mysql呐级别的就不用说了，hfs，redis，mongdb。新生存储系统还是相当活跃给力的。

存储现在遇见几个问题。
数据如何迁移。
小文件存储如何提高性能
海量数据备份
还有一个就是，这些数据如何在存储的过程中，灵活的应用。这很关键。存下只是基本的需求。好用才行。


现在要想扩展文件系统，Linux提供了一个不错的机制。虚拟文件系统，利用该机制可以灵活的开发自己的文件系统，目前正在研究ing。希望有高手指点一下。
作者: crazyhadoop    时间: 2011-12-02 13:02
本帖最后由 crazyhadoop 于 2011-12-02 13:06 编辑

回复 1# send_linux


发重了
作者: send_linux    时间: 2011-12-02 13:51
Linux存储难道只是文件系统？
没有IPSAN、FC SAN、IB SAN？
没有数据压缩、重复数据删除、自动精简配置、 ...
yuanbor 发表于 2011-12-02 11:56



    欢迎兄弟发布高见，嘿嘿，他们都是文件系统方面的，欢迎底层的偏硬件控制方面一些讨论：）
作者: yuanbor    时间: 2011-12-02 13:56
欢迎兄弟发布高见，嘿嘿，他们都是文件系统方面的，欢迎底层的偏硬件控制方面一些讨论：）
send_linux 发表于 2011-12-02 13:51



    嘿嘿，我是来学习底层软硬件系统的
作者: yuanbor    时间: 2011-12-02 14:23
用标准Linux搭建一个IP SAN大家感觉哪里会出现问题，结构如下图所示：

第一步，使用RAID技术将磁盘做成一个可靠的RAID5分区（也可以整多个）；
第二步，使用LVM技术将其分成多个合适大小的小分区供用户使用；
第三步，使用开源的iSCSI Target，比如tgt、scst或者iet，将这些分区抛给用户使用；
作者: ao_qy    时间: 2011-12-02 14:40
回复 20# crazyhadoop


Linux文件系统的设计确实巧妙。它基于公共文件模型在具体文件系统和上层应用之间引入了Linux VFS层，将各种不同文件系统的操作和管理纳入一个统一的框架，使得用户不需要关心各种不同文件系统的实现细节。它为上层应用程序提供统一的系统调用，以及可预期的处理逻辑。而相对于具体文件系统，则是各种具体对象的公共属性以及操作接口的提取。也就是说，对于涉及具体文件系统的行为，由具体文件系统实现，并通过精炼提取的API注册到Linux VFS。此外，它还有一个重要的设计思想，即“一切都是文件”。
从内核实现来讲，Linux文件系统的故事就是文件系统类型、超级块、inode、dentry 和vfsmount 这几个关键对象之间的故事。《存储技术原理分析——基于Linux2.6内核源代码》第八章对此进行了详细的概括，从中摘取几张图片帮助理解：




作者: ao_qy    时间: 2011-12-02 14:44
回复 24# yuanbor

同样的结构，我的画法是：
作者: yuanbor    时间: 2011-12-02 14:47
回复 26# ao_qy
好
作者: yuanbor    时间: 2011-12-02 14:59
回复  yuanbor

同样的结构，我的画法是：
ao_qy 发表于 2011-12-02 14:44


我想要这个文档
作者: wait_rabbit    时间: 2011-12-02 15:08
还在啃VFS的新手战战兢兢飘过。

刚买了这本书，书很厚，但含量也相当足，呵呵。对作者表示一下感谢。
作者: ao_qy    时间: 2011-12-02 15:10
回复 28# yuanbor

呵呵，这是几年前搞的东西，详细文档已经很难找了。稍微概括了几句话，和这一张图一起，写到《存储技术原理——基于Linux2.6内核源代码》书里面了。俺查了一下，免费试读中没有这部分内容。
作者: T-Bagwell    时间: 2011-12-02 15:10
linux的下一代fs,brtfs不知道什么时候release啊,应该和zfs有一拼
chenyx 发表于 2011-12-01 09:56


不是早就release了吗？
安装的时候已经可以选择了
作者: T-Bagwell    时间: 2011-12-02 15:12
回复  crazyhadoop


Linux文件系统的设计确实巧妙。它基于公共文件模型在具体文件系统和上层应用之间引 ...
ao_qy 发表于 2011-12-02 14:40



    这种设计图其实在很多地方都可以使用，设计得确实很好
    上周日搞了以下，给mm使用去了，mm感动得拿过去做毕业设计去的框架去了，呵呵
作者: ao_qy    时间: 2011-12-02 15:28
回复 29# wait_rabbit


谢谢你的支持！这本书的内容决定了读者群会比较窄，没想到在出版之后销量还可以，也算是对以前付出的一点安慰。
由于分析的是Linux存储的实现机制，所以不可避免地要把代码贴上去。我反复琢磨了书中选取的函数，基本上都是对分析流程不可或缺的。之所以把这些函数的代码完整地囊括进来，最初是希望书的内容是自包含的，也就是读者在阅读的时候不需要到网上再去查找代码。后来看到读者建议选取函数关键语句进行分析，也不失为一种方式，只能留待以后再操作了。
我自己最大的不满意之处就是，书中代码字体应该可以小一些（可惜出版前最后一版，我没有看到全文排版），这样就不会显得这么厚。
作者: chenyx    时间: 2011-12-02 15:32
回复 31# T-Bagwell


    我刚刚编译linux3.1内核的时候,brtfs还是供开发使用呢
作者: crazyhadoop    时间: 2011-12-02 16:30
回复 33# ao_qy


    毛老师那本书的思路很不错～～ 要是能像那样分析问题就帅了
作者: ao_qy    时间: 2011-12-02 16:48
回复 35# crazyhadoop


毛老师的书是Linux存储领域的一本经典，也是我案头常备的参考书之一。请相信我，《存储技术原理分析——基于Linux2.6内核源代码》会带给你一个新的分析Linux存储的角度。
作者: crazyhadoop    时间: 2011-12-02 16:55
回复 36# ao_qy


    嗯～～期待呢～～ 这个领域还有好多事可以做
作者: royzs    时间: 2011-12-02 17:21
存储还是支持硬件哇，软件的比较没有安全感
作者: milujite    时间: 2011-12-02 18:59
回复  wait_rabbit


谢谢你的支持！这本书的内容决定了读者群会比较窄，没想到在出版之后销量还可以， ...
ao_qy 发表于 2011-12-02 15:28



   感觉比较偏向开发人员，不过类似<<UNIX环境高级编程>>这种我也爱看，主要是能对系统有更深了解，能够解释平时在使用中的一些问题，利于排障。前面的那几个图很销魂啊～收下了。之前还以为这个帖子偏向管理员的。看来理解错了。哈哈，围观学习～
作者: milujite    时间: 2011-12-02 19:02
存储还是支持硬件哇，软件的比较没有安全感
royzs 发表于 2011-12-02 17:21



    其实存储隐藏的那一层，还真是个操作系统，处处都存在操作系统卷管理的影子，只是你没去注意而已。
作者: bbjmmj    时间: 2011-12-03 11:06
mooseFS的master比较烧内存，这个缺点导致了集群系统文持的文件数量大大受限。另外一个比较大的问题是它的那个HASH排序，HASH空间太小，文件多时，树的深度可能很大，这个缺点决定了它的CHUNK索引只能放在内存里面，而内存又限制了文件数量。
KFS很好地避免了mooseFS文件数量限制的缺点，在排序上也大有改进，不那么烧内存了，不过坑爹的是它不是POSIX兼容的，也就是不支持文件owner、group、可执行等属性。
reiserFS、BTRFS和XFS都是B树排序的，都是对EXT3的改进，本质上相差不大，这几个文件系统都比较怕树的损坏，因此对存储设备可靠性要求比较苛刻。
ZFS受制于版权，严重不看好它。
GLUSTERFS，排序用了红黑树。缺点是加了brick以后需要find *，它不会自动同步，这个毛病挺烦人的。不过话说mooseFS也这样。没有自动同步，集群节点数就会受到限制，因为允许同时更换或损坏的brick比较少。

我琢磨目前所有分布式文件系统都应该做些改进，比如，对于热点数据，自动增加镜象数量，等等。
作者: milujite    时间: 2011-12-03 15:35
大神，你把BTRFS和XFS还有REISERFS放一起，虽然都是B树，但是BTRFS和ZFS才是同一类型的文件系统，都是为下一代文件系统设计的，实现存储集中管理以及事务特性等等。

在内存这么便宜的年代，我觉得MOOSEFS meta信息存储读取到内存里不是什么缺点，相比SAS和SATA的容量和价格差，内存真不算啥。
作者: bbjmmj    时间: 2011-12-03 23:57
大神，你把BTRFS和XFS还有REISERFS放一起，虽然都是B树，但是BTRFS和ZFS才是同一类型的文件系统，都是为下一 ...
milujite 发表于 2011-12-03 15:35



    BTRFS和ZFS所谓的“下一代”是针对EXT3说的，主要的改进是在目录索引上，但是我觉得跟reiserfs相比，算不上是什么进步。
    内存容量的增长速度显然落后于硬盘，mooseFS烧内存的做法是相当不明智的。它的CHUNK排序做得很粗糙，HASH，很不靠谱。MFS的优点是它有回收站，可以找回误删的文件。
作者: beyondfly    时间: 2011-12-04 10:26
目前Linux的文件系统ext3应该还是主流，ext4在最近的发行版如RHEL6, Fedora16中，也成了主流了。就具体的使用来说，我觉得小企业可以NFS会用得多，把一台大容量的机器做为存储服务器，ftp, samba之间的目录可做为NFS的挂载目录，普通用户可以通过ftp，samba等方式来使用服务器的数据，而系统管理员之类的用户则可以通过NFS方式来上传或是下载数据。
   btrfs文件系统没有使用过，不知道性能如何，ZFS文件系统的快照功能，这个在目录看来是比较有市场的，而且是特别适合于开发人员进行还原操作。
作者: beyondfly    时间: 2011-12-04 10:30
RAID这玩意，分为软RAID和硬件RAID，如果从操作系统层来说，应该是指是软RAID了
作者: bbjmmj    时间: 2011-12-04 14:39
回复 44# beyondfly


    ZFS快照不能用LVM快照替代吗？
作者: saintdragon    时间: 2011-12-04 23:33
淘宝声称将TBFS开源，FastDFS和TBFS相比，有何优缺点？或者说应用场景不同？
作者: royzs    时间: 2011-12-05 09:46
其实存储隐藏的那一层，还真是个操作系统，处处都存在操作系统卷管理的影子，只是你没去注意而已 ...
milujite 发表于 2011-12-02 19:02



       深了，有点吃不动了，我再钻研钻研
作者: waily    时间: 2011-12-05 11:20
回复 15# ao_qy


    看了样章，比那个大话存储牛逼
作者: tomac_cu    时间: 2011-12-05 12:14
mooseFS的master比较烧内存，这个缺点导致了集群系统文持的文件数量大大受限。另外一个比较大的问题是它的那 ...
bbjmmj 发表于 2011-12-03 11:06



    难得见到bj大神正28J的谈技术，佩服
作者: bbjmmj    时间: 2011-12-05 12:19
难得见到bj大神正28J的谈技术，佩服
tomac_cu 发表于 2011-12-05 12:14



    我不可能总正经
作者: mirnshi    时间: 2011-12-05 15:14
回复 41# bbjmmj

ZFS受制于啥版权？
作者: bbjmmj    时间: 2011-12-05 15:14
回复  bbjmmj

ZFS受制于啥版权？
mirnshi 发表于 2011-12-05 15:14



    它！是！ORACLE！的！
作者: mirnshi    时间: 2011-12-05 15:20
它！是！ORACLE！的！
bbjmmj 发表于 2011-12-05 15:14


zfs的版权是CDDL的，商业公司与什么版权是2回事。
作者: milujite    时间: 2011-12-05 19:52
zfs的版权是CDDL的，商业公司与什么版权是2回事。
mirnshi 发表于 2011-12-05 15:20



    Linus好像是希望以GPL来使用，所以跟SUN没谈好吧。
甲骨文的开源产品还挺多的，虽然有时候做法有点恶心～
作者: mirnshi    时间: 2011-12-05 20:21
Linus好像是希望以GPL来使用，所以跟SUN没谈好吧。
甲骨文的开源产品还挺多的，虽然有时候做法有 ...
milujite 发表于 2011-12-05 19:52



  SUN不是小公司，怎么会屈服GPL呢。FSF很多事情都是看着不顺眼的。
作者: ao_qy    时间: 2011-12-05 21:33
回复 49# waily


我私下和《大话存储》的作者是相熟的朋友，他是一个很努力、很痴迷于技术的人。不管谁写东西出来，总是有人褒，有人扁，这是很正常的，都应该习惯。但是，我们应该鼓励有更多的作品出来，不是么？
作者: to407    时间: 2011-12-05 22:57
回复 56# mirnshi


    http://zfsonlinux.org/faq.html#WhatAboutTheLicensingIssue

    关于这一段zfs的CDDL license内容说明，应该说 zfs的CDDL license是OPEN，但OPEN并不是GPL的同义词。
    CDDL并没有什么大问题，如果说有什么能被GNU/linux kernel那边的人称为问题的话，那就是说 zfs采用了一个 non-GPL compatible license.

    只不过是不循GPL而已。而且上面的链接中也给出了在linux上的相关解决方案。

    Linux的GPL有讲了分享，但却没有重视"回馈"，这才是重点。
作者: to407    时间: 2011-12-05 23:03
回复 45# beyondfly


    如果不是在硬件层实现的，就可以看成是soft raid... linux相关的可以看这个链接

   http://tldp.org/HOWTO/Software-RAID-HOWTO-5.html
作者: to407    时间: 2011-12-05 23:09
回复 44# beyondfly


    关于你说的NFS分享资料的环境，我觉得比如分享数据资料，单位内部的信息，甚至大型软件的二进制共享，都可以做成基于NAS的协议，因为这些数据 大文件分享的话一般只读的 比较多。 可以用NFS，也可以用CIFS/SAMBA来跨OS分享.

    至于一些需要大I/O的话, NAS可能就有网络瓶颈了， 比如一些业务系统 数据库存储， SAN是一个比较常见的解决方案。~

    这个小企业解决起来都不难，成本不高。
作者: to407    时间: 2011-12-05 23:16
回复 12# jerryjzm


    ASM的设计理念是想把所有ORACLE相关的文件放上去。 有一点是值得称赞的， 让DBA或者SA在安装和管理数据库的时候，底层直接跟ASM打交道，省去了直接和不同的存储硬件去做直接的操作，相当于加了层接口。

   ASM上面有一层ADVM接口，再往上有一个ACFS的实现，这个ACFS在很多客户的生产环境中已经应用了，有做ORACLE相关的可以关注。
作者: waily    时间: 2011-12-06 14:21
回复 57# ao_qy


    你也够神了，05年注册后潜水6年，现在才出来冒泡
作者: ao_qy    时间: 2011-12-06 16:32
本帖最后由 ao_qy 于 2011-12-06 21:20 编辑

在Linux存储中，RAID一直是大家反复谈论的话题，概念和分类已经被网络传来传去的文章炒透了。Linux RAID5/6的分析虽有，却极少，并且都没有精确解释add_stripe_bio这个关键函数。我在苦思冥想后整理了下面的分析，供大家参考。



摘自《存储技术原理分析——基于Linux2.6内核源代码》第469/470页。
作者: todaygood    时间: 2011-12-07 07:20
回复 14# milujite


    讲得很好！顶！
作者: kns1024wh    时间: 2011-12-07 09:41
回复 1# send_linux


   谈及存储技术，就会考虑文件系统的表现形式。 linux 下的存储是根据需求而产生的，针对服务器linux与的extX NFS  mooseFS ASM  FastDFS Lustre Hadoop等涉及的存储技术、以及裸设备的存储技术都是在各类磁盘存储器；针对嵌入式的 jffs2, yaffs, cramfs, romfs, ramdisk, ramfs/tmpfs等嵌入式的文件系统的存储设备为 RAM(DRAM, SDRAM)和ROM(常采用FLASH存储器)；
   
  不同的领域里面的存储定义的概念和需求实现方式也各有不同，在特定的应用环境中来分析存储特性才是合理的选择。

  在嵌入式的领域基于FLASH的文件系统和基于RAM的文件系统的文件系统就是用在不同的应用中，如同服务器领域中一套系统中存在多种的存储技术。

基于FLASH的文件系统
Jffs2: 日志闪存文件系统版本2 (Journalling Flash FileSystem v2)
　　主要用于NOR型闪存，基于MTD驱动层，特点是：可读写的、支持数据压缩的、基于哈希表的日志型文件系统，并提供了崩溃/掉电安全保护，提供“写平衡”支持等。缺点主要是当文件系统已满或接近满时，因为垃圾收集的关系而使jffs2的运行速度大大放慢。
jffsx不适合用于NAND闪存主要是因为NAND闪存的容量一般较大，这样导致jffs为维护日志节点所占用的内存空间迅速增大，另外，jffsx文件系统在挂载时需要扫描整个FLASH的内容，以找出所有的日志节点，建立文件结构，对于大容量的NAND闪存会耗费大量时间。

yaffs/yaffs2是专为嵌入式系统使用NAND型闪存而设计的一种日志型文件系统。与jffs2相比，它减少了一些功能(例如不支持数据压缩)，所以速度更快，挂载时间很短，对内存的占用较小。另外，它还是跨平台的文件系统，除了Linux和eCos，还支持WinCE, pSOS和ThreadX等。
affs/yaffs2自带NAND芯片的驱动，并且为嵌入式系统提供了直接访问文件系统的API，用户可以不使用Linux中的MTD与VFS，直接对文件系统操作。当然，yaffs也可与MTD驱动程序配合使用。
　　yaffs与yaffs2的主要区别在于，前者仅支持小页(512 Bytes) NAND闪存，后者则可支持大页(2KB) NAND闪存。同时，yaffs2在内存空间占用、垃圾回收速度、读/写速度等方面均有大幅提升。

Cramfs是Linux的创始人 Linus Torvalds参与开发的一种只读的压缩文件系统。它也基于MTD驱动程序。
Cramfs文件系统以压缩方式存储，在运行时解压缩，所以不支持应用程序以XIP方式运行，所有的应用程序要求被拷到RAM里去运行，但这并不代表比Ramfs需求的RAM空间要大一点，因为Cramfs是采用分页压缩的方式存放档案，在读取档案时，不会一下子就耗用过多的内存空间，只针对目前实际读取的部分分配内存，尚没有读取的部分不分配内存空间，当我们读取的档案不在内存时，Cramfs文件系统自动计算压缩后的资料所存的位置，再即时解压缩到RAM中。


基于RAM的文件系统
Ramdisk是将一部分固定大小的内存当作分区来使用。它并非一个实际的文件系统，而是一种将实际的文件系统装入内存的机制，并且可以作为根文件系统。将一些经常被访问而又不会更改的文件(如只读的根文件系统)通过Ramdisk放在内存中，可以明显地提高系统的性能。
在Linux的启动阶段，initrd提供了一套机制，可以将内核映像和根文件系统一起载入内存。

Ramfs是Linus Torvalds开发的一种基于内存的文件系统，工作于虚拟文件系统(VFS)层，不能格式化，可以创建多个，在创建时可以指定其最大能使用的内存大小。(实际上，VFS本质上可看成一种内存文件系统，它统一了文件在内核中的表示方式，并对磁盘文件系统进行缓冲。)
Ramfs/tmpfs文件系统把所有的文件都放在RAM中，所以读/写操作发生在RAM中，可以用ramfs/tmpfs来存储一些临时性或经常要修改的数据，例如/tmp和/var目录，这样既避免了对Flash存储器的读写损耗，也提高了数据读写速度。
Ramfs/tmpfs相对于传统的Ramdisk的不同之处主要在于：不能格式化，文件系统大小可随所含文件内容大小变化。
Tmpfs的一个缺点是当系统重新引导时会丢失所有数据。
作者: kns1024wh    时间: 2011-12-07 09:44
淘宝声称将TBFS开源，FastDFS和TBFS相比，有何优缺点？或者说应用场景不同？
saintdragon 发表于 2011-12-04 23:33



    开源 就是广泛的测试基础
  开源 可以集中互联网的力量发现修改bug
具体看开源的文档和内容都是那些方面的，要有足够的信息来对比
作者: tony_ayuan    时间: 2011-12-07 13:24
回复 63# ao_qy


块IO一章很赞
作者: ao_qy    时间: 2011-12-07 15:49
关于块I/O子系统对象（摘自《存储技术原理分析——基于Linux2.6内核源代码》第287页）：

    从根本上讲，块I/O 子系统的故事就是磁盘（分区）和块设备之间的故事。这里的磁盘即前面的通用磁盘的简称，它已经透明了低层的物理属性或逻辑属性，抽象出一个以块为单位的线性排列的完整实体。一个磁盘可以创建多个分区，每个分区覆盖了磁盘的一部分连续块。分区是一种比较特殊的逻辑设备，Linux 将对分区的支持集成到块I/O 子系统中，对分区的请求可以简单地被线性映射到分区所在的磁盘。磁盘本身也可以当作一个“大的分区”，因为它的分区编号为0，本书称为零号分区。其他分区从1 开始编号。如果磁盘上可以创建编号大于1或等于1 的分区，我们称这个磁盘是“可分区的”；否则称它是“不可分区的”。
    磁盘和分区都可以作为块设备“独立”使用，它们分别对应一个块设备，在对分区进行I/O 操作时，其偏移值被转换为相对于磁盘的偏移值，交付低层块设备驱动执行。它们反映了同一事物的不同方面。磁盘（分区）强调对下层的执行属性，比如对请求的处理方面；而块设备强调对上层的操作属性，例如，上层发送到块I/O 的读/写请求都是以块设备为目标的。通用磁盘、分区和块设备描述符之间的关系如图5-2 所示。
    如果说SCSI 磁盘驱动是连接块I/O 子系统和SCSI 子系统之间的的桥梁，那么也可以这样认为，块设备是联系块I/O 子系统和文件系统之间的纽带。
    系统启动过程中，检测到磁盘时，一般需要扫描其分区，在内存中构造磁盘/分区关系。在分区实用程序对磁盘分区进行改变之后，也应该通知内核更新磁盘/分区关系。
    块I/O 子系统的另一个重点在于透彻分析I/O 请求处理过程中牵涉的对象，主要包括通用块层请求和块设备驱动层请求，两种既相互关联，又相互独立。
    bio 表示上层发送给通用块层的请求，称作通用块层I/O 请求，或通用块层请求，它关注的是请求的应用层面，即读取（或写入）哪个块设备，读取（或写入）多少字节的数据，读取（或写入）到哪个目标缓冲区等。request表示通用块层为低层块设备驱动准备的请求，称作块设备驱动层I/O 请求，或块设备驱动层请求，它关注的是请求的实施层面，即构造哪种类型的SCSI 命令。
作者: happy_fish100    时间: 2011-12-08 11:11
开源 就是广泛的测试基础
  开源 可以集中互联网的力量发现修改bug
具体看开源的文档和内容都 ...
kns1024wh 发表于 2011-12-07 09:44


回答得很精辟啊！
FastDFS和TFS都是应用级的分布式文件存储系统，二者的应用场景基本上是重叠的。
至于二者各自的优缺点，感兴趣的同仁可以看一下相关的资料。
作者: T-Bagwell    时间: 2011-12-08 14:01
回复  send_linux


   谈及存储技术，就会考虑文件系统的表现形式。 linux 下的存储是根据需求而产生的 ...
kns1024wh 发表于 2011-12-07 09:41


百湖兄，现在嵌入式上面的存储越来越好了，下面用的nand，有些直接通过emmc来控制
这样，文件系统的block的使用就不用考虑那么多了，于是乎ext2/ext3/ext4就可以随便用了
比如Android 2.3在不少的新的平台上，用的就是emmc了，文件系统就是ext4
当然，之前用的还是yaffs，呵呵
作者: T-Bagwell    时间: 2011-12-08 14:06
回答得很精辟啊！
FastDFS和TFS都是应用级的分布式文件存储系统，二者的应用场景基本上是重叠的。
至 ...
happy_fish100 发表于 2011-12-08 11:11



    FastDFS不用去修改kernel部分或者在kernel部分增加支持吗？
比如 ext2支持单个最大文件1TB， 那么你的FastDFS里面支持写入1PB不？
这样的话是不是要去改ext2？
或者是将大文件打散，然后存储在不同的位置？
作者: happy_fish100    时间: 2011-12-08 15:00
FastDFS不用去修改kernel部分或者在kernel部分增加支持吗？
比如 ext2支持单个最大文件1TB， 那么你的FastDFS里面支持写入1PB不？
这样的话是不是要去改ext2？
或者是将大文件打散，然后存储在不同的位置？
T-Bagwell 发表于 2011-12-08 14:06


因为互联网在线应用的文件，通常都不大，比如不会超过100MB。FastDFS的定位就是互联网在线应用（服务）。
出于简洁考虑，FastDFS不会对大文件进行分块存储，因此支持的最大文件受限于本地文件系统，比如ext3，或者你所说的ext2。
作者: kns1024wh    时间: 2011-12-08 22:17
百湖兄，现在嵌入式上面的存储越来越好了，下面用的nand，有些直接通过emmc来控制
这样，文件系统的bl ...
T-Bagwell 发表于 2011-12-08 14:01



    或者转换一个角度来说 ， 嵌入式文件系统使用数量要远远多于在服务器中使用的文件系统的数量，手机、移动设备等电子产品比比皆是。
作者: to407    时间: 2011-12-08 22:23
因为互联网在线应用的文件，通常都不大，比如不会超过100MB。FastDFS的定位就是互联网在线应用（服务） ...
happy_fish100 发表于 2011-12-08 15:00



    我是觉得这边是不是可以再想点别的。。。如果只是依赖于底层的ext3。。。那么I/O性能并不可能有质的变化，为什么不以VFS为接口作一个兼容的FS呢。。。纯吐槽。。。
作者: blue_stone    时间: 2011-12-09 11:34
偶最近在研究flashcache, 有没有同学关注的.

btrfs偶已经在本本上用几个月了, 一直用的很正常
作者: to407    时间: 2011-12-09 16:09
回复 75# blue_stone

   表示估计我们碰的不是同一样东西。。。哈哈

    http://www.oracle.com/technetwor ... twp-v5-1-128560.pdf
作者: ao_qy    时间: 2011-12-15 16:05
Linux 操作系统秉承“一切都是文件”的设计思想，将所有的块设备也都看作是文件。早期Linux 系统通过手工或编写脚本执行mknod 命令来创建块设备文件。对于当前版本的Linux 系统，内核发现一个块设备时，会通知用户空间，用户空间的udevd 后台进程接收到这些消息后，会按照用户指定的规则为它创建块设备文件。
理解块设备文件，关键在于两个方面。其一，从外部表现来看，它是属于某个外部文件系统上的一个文件，通常将它们存放在/dev 目录下，用户像常规文件一样通过文件名对它进行访问；其二，从内部实现来看，它又可以被看成一个特殊文件系统的一个文件，块设备文件的文件逻辑编号和块逻辑编号一一对应。
一般来说，前一个文件系统被称为宿主文件系统，通常为根文件系统，可以是各种文件系统类型。通过特殊方式来区别常规文件和块设备文件。例如Minix 文件系统采用文件磁盘i 节点格式中的i_mode 域表明文件是否对应一个块设备文件，块设备文件（Block Special File）的内容是块设备编号（主设备号和次设备号），被保存在块设备文件的磁盘上i 节点的i_zone[0]域。
而后一个文件系统就是下面要讲到的bdev 文件系统，它是一个“伪”文件系统，它存在的目的就是建立块设备文件的外部表现和内部实现之间的联系。bdev 文件系统只被内核使用，并不需要装载到全局文件系统树上。
8.9.1 块设备的主inode 和次inode
和常规文件不同的是，块设备文件除了上面在根文件系统中的inode 以外，在bdev 文件系统上也有一个相应的inode。两个inode 之间通过块设备编号相关联。为了区别，我们将在宿主文件系统中的inode 称为块设备文件的次inode（slave inode），而在bdev 文件系统上的inode 称为块设备文件的主inode（master inode）。
1．宿主文件系统的块设备文件inode
在Linux 系统中，存在一个抽象化的设备目录，名为/dev。该目录下存有指向系统中硬件的特殊文件。这些指向硬件设备的文件，极大地简化了程序员对硬件的操作。因为，程序员就可以像访问普通文件一样来访问硬件，而无须使用特殊的接口函数。
宿主文件系统上的块设备文件对应的inode 具有如下特性：
* 文件模式为块设备文件；
* 文件内容为块设备编号，保存在磁盘inode 中。这一点和fast symlink 相同；
* 文件长度为0。
如果根文件系统是Minix 文件系统，则块设备文件的inode 示意图，如图8-33 所示。

以上摘自《存储技术原理分析——基于Linux2.6内核源代码》第761～762页。
作者: crazyhadoop    时间: 2011-12-15 21:08
虚拟化存储未来要如何发展了？
作者: send_linux    时间: 2011-12-16 00:44
回复  blue_stone

   表示估计我们碰的不是同一样东西。。。哈哈
to407 发表于 2011-12-09 16:09



    学习一下，呵呵
作者: shang2010    时间: 2011-12-20 11:33
怎么没有人谈
OpenAFS


http://www.scientificlinux.org/
作者: send_linux    时间: 2011-12-29 09:35
shang2010 发表于 2011-12-20 11:33
怎么没有人谈
OpenAFS


欢迎兄弟分享分享啊，呵呵
作者: baiyun120    时间: 2012-03-16 14:37
:wink::wink:
作者: qd520000    时间: 2012-03-23 10:19
是不错的.安全很多..
作者: jiyuwoaa    时间: 2012-04-03 21:15
俺是linux菜鸟哦  需要多多学习
作者: cu_vieri    时间: 2014-10-07 21:12
:((:D):D):D):D):PP
作者: milujite    时间: 2014-10-08 15:07
blue_stone 发表于 2011-12-09 11:34
偶最近在研究flashcache, 有没有同学关注的.

btrfs偶已经在本本上用几个月了, 一直用的很正常


BTRFS还远不够成熟，ZFS很多功能在BTRFS上还没实现。。。



欢迎光临 Chinaunix (http://bbs.chinaunix.net/) Powered by Discuz! X3.2