精华内容
下载资源
问答
  • SAN 和 NAS 的不足,国际上已开展针对 Linux 集群的新型文件系统――对象存储文件系统的研究,本文重点论述了存储对象文件系统的架构、技术特点,并针对Lustre 对象存储文件系统进行了初步测试,结果表明对象存储...
     
    

    随着高性能计算由传统的主机方式向网络化集群演变,传统的基于主机的存储架构已逐渐向网络化存储发展,计算和存储分离的趋势越来越明显。针对 SAN 和 NAS 的不足,国际上已开展针对 Linux 集群的新型文件系统――对象存储文件系统的研究,本文重点论述了存储对象文件系统的架构、技术特点,并针对Lustre 对象存储文件系统进行了初步测试,结果表明对象存储文件系统在可扩展性、性能、易用性等方面都有显著提高,随着网络化存储技术的不断成熟,对象存储文件系统将成为重要的发展方向。

    一、引言

    高性能计算已由传统的主机方式逐渐向集群方式演变,如TOP500中,1998年只有2台系统是集群方式,而到2003年已有208台为集群系统。随着高性能计算体系结构的发展变化,传统的基于主机的存储架构已成为新的瓶颈,不能满足集群系统的需求。集群的存储系统必须有效解决两个主要问题:(1)提供共享访问数据,便于集群应用程序的编写和存储的负载均衡;(2)提供高性能的存储,在I/O级和数据吞吐率方面能满足成百上千台规模的Linux集群服务器聚合访问的需求。目前,网络化存储已成为解决集群系统高性能存储的有效技术途径。

    国际上主要有两类网络化存储架构,它们是通过命令集来区分的。第一类是SAN(Storage Area Network)结构,它采用SCSI 块I/O的命令集,通过在磁盘或FC(Fiber Channel)级的数据访问提供高性能的随机I/O和数据吞吐率,它具有高带宽、低延迟的优势,在高性能计算中占有一席之地,如SGI的CXFS文件系统就是基于SAN实现高性能文件存储的,但是由于SAN系统的价格较高,且可扩展性较差,已不能满足成千上万个CPU规模的系统。第二类是NAS(Network Attached Storage)结构,它采用NFS或CIFS命令集访问数据,以文件为传输协议,通过TCP/IP实现网络化存储,可扩展性好、价格便宜、用户易管理,如目前在集群计算中应用较多的NFS文件系统,但由于NAS的协议开销高、带宽低、延迟大,不利于在高性能集群中应用。

    针对Linux集群对存储系统高性能和数据共享的需求,国外已开始研究全新的存储架构和新型文件系统,希望能有效结合SAN和NAS系统的优点,支持直接访问磁盘以提高性能,通过共享的文件和元数据以简化管理,目前对象存储文件系统已成为Linux集群系统高性能文件系统的研究热点,如Cluster File Systems公司的Lustre、Panasas公司的ActiveScale文件系统等。Lustre文件系统采用基于对象存储技术,它来源于卡耐基梅隆大学的Coda项目研究工作,2003年12月发布了Lustre 1.0版,预计在2005年将发布2.0版。Lustre在美国能源部(U.S.Department of Energy:DOE)、Lawrence Livermore 国家实验室,Los Alamos国家实验室,Sandia 国家实验室,Pacific Northwest国家实验室的高性能计算系统中已得到了初步的应用,IBM正在研制的Blue Gene系统也将采用Lustre文件系统实现其高性能存储。ActiveScale文件系统技术来源于卡耐基梅隆大学的Dr. Garth Gibson,最早是由DARPA支持的NASD(Network Attached Secure Disks)项目,目前已是业界比较有影响力的对象存储文件系统,荣获了ComputerWorld 2004年创新技术奖。

    回页首

    二、对象存储文件系统

    2.1 对象存储文件系统架构

    对象存储文件系统的核心是将数据通路(数据读或写)和控制通路(元数据)分离,并且基于对象存储设备(Object-based Storage Device,OSD)构建存储系统,每个对象存储设备具有一定的智能,能够自动管理其上的数据分布,对象存储文件系统通常有以下几部分组成。

    1、对象

    对象是系统中数据存储的基本单位,一个对象实际上就是文件的数据和一组属性的组合,这些属性可以定义基于文件的RAID参数、数据分布和服务质量等,而传统的存储系统中用文件或块作为基本的存储单位,在块存储系统中还需要始终追踪系统中每个块的属性,对象通过与存储系统通信维护自己的属性。在存储设备中,所有对象都有一个对象标识,通过对象标识OSD命令访问该对象。通常有多种类型的对象,存储设备上的根对象标识存储设备和该设备的各种属性,组对象是存储设备上共享资源管理策略的对象集合等。

    2、对象存储设备

    对象存储设备具有一定的智能,它有自己的CPU、内存、网络和磁盘系统,目前国际上通常采用刀片式结构实现对象存储设备。OSD提供三个主要功能:

    (1) 数据存储。OSD管理对象数据,并将它们放置在标准的磁盘系统上,OSD不提供块接口访问方式,Client请求数据时用对象ID、偏移进行数据读写。

    (2) 智能分布。OSD用其自身的CPU和内存优化数据分布,并支持数据的预取。由于OSD可以智能地支持对象的预取,从而可以优化磁盘的性能。

    (3) 每个对象元数据的管理。OSD管理存储在其上对象的元数据,该元数据与传统的inode元数据相似,通常包括对象的数据块和对象的长度。而在传统的NAS系统中,这些元数据是由文件服务器维护的,对象存储架构将系统中主要的元数据管理工作由OSD来完成,降低了Client的开销。

    3、元数据服务器(Metadata Server,MDS)

    MDS控制Client与OSD对象的交互,主要提供以下几个功能:

    (1) 对象存储访问。MDS构造、管理描述每个文件分布的视图,允许Client直接访问对象。MDS为Client提供访问该文件所含对象的能力,OSD在接收到每个请求时将先验证该能力,然后才可以访问。

    (2) 文件和目录访问管理。MDS在存储系统上构建一个文件结构,包括限额控制、目录和文件的创建和删除、访问控制等。

    (3) Client Cache一致性。为了提高Client性能,在对象存储文件系统设计时通常支持Client方的Cache。由于引入Client方的Cache,带来了Cache一致性问题,MDS支持基于Client的文件Cache,当Cache的文件发生改变时,将通知Client刷新Cache,从而防止Cache不一致引发的问题。

    4、对象存储文件系统的Client

    为了有效支持Client支持访问OSD上的对象,需要在计算结点实现对象存储文件系统的Client,通常提供POSIX文件系统接口,允许应用程序像执行标准的文件系统操作一样。

    2.2 对象存储文件系统的关键技术

    1、分布元数据 传统的存储结构元数据服务器通常提供两个主要功能。(1)为计算结点提供一个存储数据的逻辑视图(Virtual File System,VFS层),文件名列表及目录结构。(2)组织物理存储介质的数据分布(inode层)。对象存储结构将存储数据的逻辑视图与物理视图分开,并将负载分布,避免元数据服务器引起的瓶颈(如NAS系统)。元数据的VFS部分通常是元数据服务器的10%的负载,剩下的90%工作(inode部分)是在存储介质块的数据物理分布上完成的。在对象存储结构,inode工作分布到每个智能化的OSD,每个OSD负责管理数据分布和检索,这样90%的元数据管理工作分布到智能的存储设备,从而提高了系统元数据管理的性能。另外,分布的元数据管理,在增加更多的OSD到系统中时,可以同时增加元数据的性能和系统存储容量。

    2、并发数据访问 对象存储体系结构定义了一个新的、更加智能化的磁盘接口OSD。OSD是与网络连接的设备,它自身包含存储介质,如磁盘或磁带,并具有足够的智能可以管理本地存储的数据。计算结点直接与OSD通信,访问它存储的数据,由于OSD具有智能,因此不需要文件服务器的介入。如果将文件系统的数据分布在多个OSD上,则聚合I/O速率和数据吞吐率将线性增长,对绝大多数Linux集群应用来说,持续的I/O聚合带宽和吞吐率对较多数目的计算结点是非常重要的。对象存储结构提供的性能是目前其它存储结构难以达到的,如ActiveScale对象存储文件系统的带宽可以达到10GB/s。

    2.3 Lustre对象存储文件系统

    Lustre对象存储文件系统就是由客户端(client)、存储服务器(OST,Object Storage Target)和元数据服务器(MDS)三个主要部分组成。Lustre的客户端运行Lustre文件系统,它和OST进行文件数据I/O的交互,和MDS进行命名空间操作的交互。为了提高Lustre文件系统的性能,通常Client、OST和MDS是分离,当然这些子系统也可以运行在同一个系统中。其三个主要部分如图1所示.


    图1 Lustre文件系统的组成
    图1 Lustre文件系统的组成 

    Lustre是一个透明的全局文件系统,客户端可以透明地访问集群文件系统中的数据,而无需知道这些数据的实际存储位置。客户端通过网络读取服务器上的数据,存储服务器负责实际文件系统的读写操作以及存储设备的连接,元数据服务器负责文件系统目录结构、文件权限和文件的扩展属性以及维护整个文件系统的数据一致性和响应客户端的请求。 Lustre把文件当作由元数据服务器定位的对象,元数据服务器指导实际的文件I/O请求到存储服务器,存储服务器管理在基于对象的磁盘组上的物理存储。由于采用元数据和存储数据相分离的技术,可以充分分离计算和存储资源,使得客户端计算机可以专注于用户和应用程序的请求;存储服务器和元数据服务器专注于读、传输和写数据。存储服务器端的数据备份和存储配置以及存储服务器扩充等操作不会影响到客户端,存储服务器和元数据服务器均不会成为性能瓶颈。

    Lustre的全局命名空间为文件系统的所有客户端提供了一个有效的全局唯一的目录树,并将数据条块化,再把数据分配到各个存储服务器上,提供了比传统SAN的"块共享"更为灵活的共享访问方式。全局目录树消除了在客户端的配置信息,并且在配置信息更新时仍然保持有效。

    回页首

    三、测试和结论

    1、Lustre iozone测试

    针对对象存储文件系统,我们对Lustre文件系统作了初步测试,具体配置如下: 
    3台双至强系统:CPU:1.7GHz,内存:1GB,千兆位以太网 
    Lustre文件系统:lustre-1.0.2 
    Linux版本:RedHat 8 
    测试程序:iozone 
    测试结果如下:

    块写(MB/s/thread) 单线程 两个线程
    Lustre 1个OST 2个OST 1个OST 2个OST
    21.7 50 12.8 24.8
    NFS 12 5.8

    从以上的测试表明,单一OST的写带宽比NFS好,2个OST的扩展性很好,显示strip的效果,两个线程的聚合带宽基本等于饱和带宽,但lustre客户方的CPU利用率非常高(90%以上),测试系统的规模(三个节点)受限,所以没有向上扩展OST和client数量。另外,lustre的cache对文件写的性能提升比NFS好。通过bonnie++初步测试了lustre的元数据处理能力,和NFS比,文件创建速度相对快一些,readdir速度慢。

    2、lustre小规模测试数据

    (文件写测试,单位KB/s):

    硬件:Dual Xeon1.7,GigE, SCSI Ultra160 软件:RedHat8,iozone


    图2 2个OST / 1个MDS
    图2  2个OST / 1个MDS 

    图3 1个OST/1个MDS
    图3  1个OST/1个MDS 

    图4 NFS测试
    图4  NFS测试 

    从初步的测试看,lustre的性能和可扩展性都不错。与传统的文件系统相比,对象存储文件系统具有以下优势:

    (1)性能。对象存储体系结构没有其它共享存储系统中的元数据管理器瓶颈。NAS系统使用一个集中的文件服务器作为元数据管理器,一些SAN文件系统则采用集中的锁管理器,最后元数据管理将成为一个瓶颈。对象存储体系结构类似于SAN,每个结点都可以直接访问它的存储设备。对象存储体系结构对SAN的改进是没有RAID控制器的瓶颈问题,当计算结点的规模增大时,该优势将非常明显,所有结点的总吞吐率最后将受限于存储系统的规模和网络的性能。存储对象结点发送数据到OSD,OSD自动优化数据的分布,这样减少了计算结点的负担,并允许向多个OSD并行读写,最大化单个Client的吞吐率。

    (2)可扩展性。将负载分布到多个智能的OSD,并用网络和软件将它们有机结合起来,消除了可扩展问题。一个对象存储系统有内存、处理器、磁盘系统等,允许它们增加其存储处理能力而与系统其它部分无关。如果对象存储系统没有足够的存储处理能力,可以增加OSD,确保线性增加性能。

    (3)OSD分担主要的元数据服务任务。元数据管理能力通常是共享存储系统的瓶颈,所有计算结点和存储结点都需要访问它。在对象存储结构中,元数据服务有两部分组成:inode元数据,管理介质上的存储块分布;文件元数据,管理文件系统的文件层次结构和目录。对象存储结构增加了元数据访问的可扩展,OSD负责自己的inode元数据,增加一个OSD可以增加磁盘容量,并可以增加元数据管理资源。而传统的NAS服务器增加更多的磁盘,则性能将更慢。对象存储系统在容量扩展时,确保持续的吞吐率。

    (4)易管理。智能化的分布对象存储结构可以简化存储管理任务,可以简化数据优化分布的任务。例如,新增存储容量可以自动合并到存储系统中,因为OSD可以接受来自计算结点发出的对象请求。系统管理员不需要创建LUN,不需要重新调整分区,不需要重新平衡逻辑卷,不需要更新文件服务器等。RAID块可自动扩展到新的对象,充分利用新增的OSD。

    (5)安全。传统的存储系统通常依赖于Client的身份认证和私有的网络确保系统安全。对象存储结构在每个级别都提供安全功能,主要包括存储设备的身份认证,计算结点的身份认证,计算结点命令的身份认证,所有命令的完整性检查,基于IPSec的私有数据和命令等。这些安全级别可以确保用户使用更高效、更易获得的网络,如以太网等。 目前panasas已经推出了商业化的对象存储全局文件系统ActiveScale,对象存储正在被重视,Lustre也已经在(ALC、MCR)或将(RedStorm)在多个大规模集群上应用,因而对象存储文件系统将成为未来集群存储的重要发展方向。

    回页首

    四、致谢

    本文的测试工作得到了并行文件系统研究小组的大力支持,特别是周恩强、董勇、林松涛、陈四建为本文提供了详实的数据,特此表示感谢。


    参考资料

    • Garth Gibson, "Scaling File Service Up and Out", USENIX FAST 2004

    • "Object Storage Architecture", Panasas White Paper

    • Peter J. Braam, "The Lustre Storage Architecture", Cluster File System, 2004

    • David Nagle, Denis Serenyi, Abbie Matthews, "The Panasas ActiveScale Storage Cluster-Delivering Scalable High Bandwidth Storage", SC2004

    • Philip Schwan, "Lustre: Building a File System for 1,000-node Clusters", OLS 2003

    • http://www.panasas.com 

    • http://www.clusterfs.com 
    展开全文
  • 文件系统对象及装载

    2013-11-25 17:56:23
    每个文件系统并不是独立使用的,相反,系统有一个公共根目录和全局文件系统树,要访问一个文件系统中的文件,必须先将这个文件系统放在全局文件系统树的某个目录下,这个过程叫文件系统挂载(mount),所装载到的...

    (注,本文中用到的图片来《自存储技术原理分析》一书)

    每个文件系统并不是独立使用的,相反,系统有一个公共根目录和全局文件系统树,要访问一个文件系统中的文件,必须先将这个文件系统放在全局文件系统树的某个目录下,这个过程叫文件系统挂载(mount),所装载到的目录叫装载点。
    文件通过路径来标识。在linux公共文件模型下,目录和符号链接也是文件,只是他们有不同的操作接口,或者有不同的操作实现,上层通过系统调用操作文件系统,linux提供open read write mount等标准系统调用接口。
    MInix是linux最早的文件系统,minix文件系统的磁盘布局由6部分组成:


    其中i节点位图用于描述磁盘块上每个i节点的使用情况,除第一个比特位外,每个比特位表示一个i节点的使用情况。而编号为1保留给跟目录对应的i节点(别忘了目录也是文件)。

    文件系统对象
    linux文件系统对象之间的关系概况为文件系统类型,超级块,inode,dentry,vfsmount之间的关系,文件系统类型规定了某种文件系统的行为,主要目的是为了构造这种类型文件系统的实例。
    超级快用于存放磁盘设备上文件系统结构的信息,在文件系统被装载时候,其内容被读入内存,用于构造内存中的超级块。其中某些信息为各种类型的文件系统所共有,被提炼成VFS超级块结构。
    inode 反映某个文件系统对象的一般元信息,dentry反映某个文件系统对象在文件系统树中的位置,与超极块相同,inode及dentry也有磁盘上,内存中及VFS三种形式,其中VFS inode,VFS superblock, VFS dentry为各个类型文件系统共有的,而磁盘上,内存中的inode和dentry为具体文件系统特有。
    linux有一颗全局文件系统树,反映linux VFS对象之间的关系,文件系统要被用户空间使用必须先装载到这棵树上,每一次装载被称为一个装载实例,某些文件系统只在内核中使用,也需要这样一个装载实例,一个文件系统装载实例四个必备元素:vfsmount,超级块,根inode跟根dentry。
    一个文件系统类型可能有多个超级块实例,而每个超级块实例可能有多个装载实例,例如,分区/dev/sda1 ,/dev/sda2都被格式化问minix文件系统类型,当/dev/sda1/ dev/sda2上的文件系统实例被挂载到/mnt/d1,/mnt/d2,则有两个超级块实例,分别对应一个装载实例,当/dev/sda1再次被挂载到/mnt/d3下,则依旧还是只有2个超级块,但这时候sda1的超级块就有两个装载实例。
    file_system_type:每种文件系统对应一个file_system_type,文件系统类型需要调用register_filesystem向VFS核心进行注册,调用unregister_filesystem从VFS中注销。
    super_block:VFS 超级块(所有文件系统共有)
    super_block描述了VFS层使用的超级块对象,对于具体的文件系统,需要定义自己的超级块对象,由super_block中的s_fs_info指向。




    s_fs-info为了效率从磁盘复制到内存,基于磁盘的文件系统在分配或者释放块时候需要访问并分配位图,VFS允许这些文件系统直接在内存中,即超级块的s_fs_info上进行操作,而无须访问磁盘。
    inode:VFS索引节点
    inode包含了文件系统各种对象(文件,目录,块设备文件,字符设备文件等)的元数据。基于磁盘的文件系统,inode存在于磁盘(bdev_inode)上,其形式取决于文件系统的类型,在打开该对象进行访问时候,其inode被读入内存(minix-inode_info),内存有一部分是各种文件系统共有的,成为VFS inode(inode结构),在打开对象时候,还根据文件系统类型和对象类型设置inode操作表和file操作表。




    下面我们看看各个结构存在的地方:
    此外,每个inode对象视其状态,总是出现在下面一个循环双链表。
    有效的未使用inode链表,这些inode不为脏,并且i_count(使用计数)为0,链表表头保存在inode_unused变量,这个链表可以看做inode缓存。
    在使用中的inode链表,这些链表不为脏,i_count域大于0,链表的表头保存在inode_in_use变量中。
    脏inode链表,链表表头为超级块bdi_writeback域的s_dirty域
    inode中有两个操作表指针,i-op及i_fop,i_op中有个函数
    int(*mknod)(struct inode*, struct dentry*,int, dev_t)他只是对代表目录的inode有意义,在目录中创建一个块(字符)special文件,同常规文件一样,块(字符)special文件也有自己的inode,但其中只需保存块(字符)special的主设备号和次设备号。
    在调用这个函数之前,已经为块(字符)设备分配了dentry,但还没有分配inode,所以该操作:1 为块设备文件新建一个具体的inode描述符。2 修改目录内容,添加一项和块设备文件对应。3 将块设备文件的VFS inode的i_rdev设置。4 将块设备文件的VFS inode和dentry关联起来
    dentry:VFS目录项
    反映的是文件系统对象在内核中所在文件系统树中的位置。
    打开对象时候,磁盘上的目录项被读取用来构造VFS dentry和内存目录项。




    vfsmount:文件系统装载
    vfsmount反映一个已装载的文件系统实例。内核代码可以通过vfsmount访问这个文件系统实例。
    有了装载关系,全局文件系统树上的一个位置就不能由dentry唯一确定了,尤其是对于一个文件系统被装载到不同的装载点上。现在文件系统的位置用 <vfsmount,dentry>表示,这就是linux内核中确定文件位置的路径
    文件系统的装载


    上面的superblock,inode,dentry都是VFS中通用的数据结构,他们分别有指针指向各自的个性化结构。只是上图没有画出来。
    上面就是一个文件系统装载实例,他们存在于linux内存中, 其他可以被内核其他部分使用,但是,如果需要从用户空间使用,就需要挂载到根文件系统上。
    假定有/dev/sda1,/dev/sda2,/dev/sda3 /dev/sda4 ,/dev/sda1为根设备,其上的文件系统为根文件系统(这四个设备文件结点都在跟文件系统的/dev/目录下)
    现在将某个设备上的文件系统装载到全局文件系统的某个目录下:
    mount -t ext3  /dev/sda2  /mnt/d
    这样将在/dev/sda2上的文件系统装载到目录/mnt/d下,/dev/sda2为包含这种类型的文件系统的设备文件名(他在之前已经被格式化为这种文件系统),/mnt/d为目标装载点,装载后,用户就可以通过/mnt/d/..访问设备 /dev/sda2上的文件系统
    在啮合角度,装载过程,文件系统类型的get_sb将被调用,生成一个新的文件系统装载对象vfsmount,并和该文件系统类型的一个超级块实例关联起来。

    mount系统调用的处理流程
    装载文件系统的系统调用入口函数是sys_mount(fs/namespace.c),五个参数
    dev_namr:包含文件系统的设备文件路径名
    dir_name:文件系统被挂载到的目标路径名
    type:文件系统类型名,必须在文件系统中已注册
    flag:装载标识
    data:文件系统特定的数据
    sys_mount—>SYSCALL_DEFINE5(将用户空间数据复制到内核空间后调用do_mount)—>do_mount
    1) do_mount->kernel_path在do_mount中,检查路径名是否有效,然后调用kernel_path,并通接着调用过它获得挂载点路径(<.vfmount,dentry>)
    2)do_mount->do_new_mount对于新建挂载,do_mount 调用do_new_mount,新建挂载的实质:(A)构造子文件系统的装载实例,也就是建立各个元素之间的关系,并最终返回指向vfsmount描述符的指针(调用do_kern_mount),(B)将子系统的装载实例“挂钩到”父文件系统的装载点(调用do_add_mount)。
    (A)do_new_mount->vfs_kernel_mount():构建文件系统装载实例,即构建vfsmount,super_block,根 dentry,根inode 间的关系(这里应该是具体的一个文件系统的根,不是全局的根文件系统的根),因为vfsmount 是一个纯内存的元素,利用alloc单独分配,其他三个与文件系统类型有关,虚调用它的get_sb回调函数完成,这样就构建了uper_block,根 dentry,根inode,并和同时传入的vfsmount关联。这中间还调用相关函数填充了内存中的超级块,以及inode位图等。
    (B)do_new_mount->do_add_mount():添加到全局文件系统树。
    路径查找
    用户空间表示文件使用路径名字符串。而内核中对文件的操作则需要super_block,inode,dentry,vfsmount.路径查找由’/”的多个部分组成,过程就是分量解析,在推进的过程中,一步步在内核中构建关系。内核中表示路径的是path

    展开全文
  • 本来想看驱动的,但发现要对驱动有底,那还得全方位的了解文件系统。 1 inode 简介  inode 是 UNIX/Linux 操作系统中的一种数据结构,其本质是结构体,它包含了与文件系统中各个文件相关的一些重要信息,例如文件...

        本来想看驱动的,但发现要对驱动有底,那还得全方位的了解文件系统。

    1   inode 简介

                inode 是 UNIX/Linux 操作系统中的一种数据结构,其本质是结构体,它包含了与文件系统中各个文件相关的一些重要信息,例如文件及目录的基本信息,包含时间、档名、使用者及群组等。在 UNIX/Linux中创建文件系统时,同时将会创建大量的 inode 。通常,文件系统磁盘空间中大约百分之一空间分配给了 inode 表。在Linux系统中,内核为每一个新创建的文件分配一个Inode(索引结点),每个文件都有一个惟一的inode号,我们可以将inode简单理解成一个指针,它永远指向本文件的具体存储位置。文件属性保存在索引结点里,在访问文件时,索引结点被复制到内存在,从而实现文件的快速访问。系统是通过索引节点(而不是文件名)来定位每一个文件。

    Block 是记录文件内容数据的区域,至于 inode 则是记录"该文件的相关属性,以及文件内容放置在哪一个 Block 之内"的信息,换句说, inode 除了记录文件的属性外,同时还必须要具有指向( pointer )的功能,亦即指向文件内容放置的区块之中,好让操作系统可以正确的去取得文件的内容,底下几个是 inode 记录的信息(当然不止这些):
              该文件的拥有者与群组(owner/group);   该文件的存取模式(read/write/excute);    该文件的类型(type);该文件建立或状态改变的时间(ctime)、最近一次的读取时间(atime)、最近修改的时间(mtime);该文件的容量;定义文件特性的旗标(flag),如 SetUID...;该文件真正内容的指向 (pointer); 文件所使用的磁盘块的实际数目;

    struct inode {
            struct hlist_node       i_hash;              /* 哈希表 */
            struct list_head        i_list;              /* 索引节点链表 */
            struct list_head        i_dentry;            /* 目录项链表 */
            unsigned long           i_ino;               /* 节点号 */
            atomic_t                i_count;             /* 引用记数 */
            umode_t                 i_mode;              /* 访问权限控制 */
            unsigned int            i_nlink;             /* 硬链接数 */
            uid_t                   i_uid;               /* 使用者id */
            gid_t                   i_gid;               /* 使用者id组 */
            kdev_t                  i_rdev;              /* 实设备标识符 */
            loff_t                  i_size;              /* 以字节为单位的文件大小 */
            struct timespec         i_atime;             /* 最后访问时间 */
            struct timespec         i_mtime;             /* 最后修改(modify)时间 */
            struct timespec         i_ctime;             /* 最后改变(change)时间 */
            unsigned int            i_blkbits;           /* 以位为单位的块大小 */
            unsigned long           i_blksize;           /* 以字节为单位的块大小 */
            unsigned long           i_version;           /* 版本号 */
            unsigned long           i_blocks;            /* 文件的块数 */
            unsigned short          i_bytes;             /* 使用的字节数 */
            spinlock_t              i_lock;              /* 自旋锁 */
            struct rw_semaphore     i_alloc_sem;         /* 索引节点信号量 */
            struct inode_operations *i_op;               /* 索引节点操作表 */
            struct file_operations  *i_fop;              /* 默认的索引节点操作 */
            struct super_block      *i_sb;               /* 相关的超级块 */
            struct file_lock        *i_flock;            /* 文件锁链表 */
            struct address_space    *i_mapping;          /* 相关的地址映射 */
            struct address_space    i_data;              /* 设备地址映射 */
            struct dquot            *i_dquot[MAXQUOTAS]; /* 节点的磁盘限额 */
            struct list_head        i_devices;           /* 块设备链表 */
            struct pipe_inode_info  *i_pipe;             /* 管道信息 */
            struct block_device     *i_bdev;             /* 块设备驱动 */
            unsigned long           i_dnotify_mask;      /* 目录通知掩码 */
            struct dnotify_struct   *i_dnotify;          /* 目录通知 */
            unsigned long           i_state;             /* 状态标志 */
            unsigned long           dirtied_when;        /* 首次修改时间 */
            unsigned int            i_flags;             /* 文件系统标志 */
            unsigned char           i_sock;              /* 可能是个套接字吧 */
            atomic_t                i_writecount;        /* 写者记数 */
            void                    *i_security;         /* 安全模块 */
            __u32                   i_generation;        /* 索引节点版本号 */
            union {
                    void            *generic_ip;         /* 文件特殊信息 */
            } u;
    };

    2  dentry简介

    dentry是Linux文件系统中某个索引节点(inode)的链接,每个dentry代表路径中的一个特定部分。这个索引节点可以是文件,也可以是目录。inode(可理解为ext2 inode)对应于物理磁盘上的具体对象,dentry是一个内存实体,没有对应的磁盘数据结构,VFS根据字符串形式的路径名现场创建他,在dentry中,d_inode成员指向对应的inode。也就是说,一个inode可以在运行的时候链接多个dentry,而d_count记录了这个链接的数量。另外dentry对象有三种状态:被使用,未被使用和负状态。

    目录项是描述文件的逻辑属性,只存在于内存中,并没有实际对应的磁盘上的描述,更确切的说是存在于内存的目录项缓存,为了提高查找性能而设计,所以它是动态生成的,这不同于inode,inode的数据并不会随进程的消亡而消失。注意不管是文件夹还是最终的文件,都是属于目录项,所有的目录项在一起构成一颗庞大的目录树。例如:open一个文件/home/xxx/yyy.txt,那么/、home、xxx、yyy.txt都是一个目录项,VFS在查找的时候,根据一层一层的目录项找到对应的每个目录项的inode,那么沿着目录项进行操作就可以找到最终的文件。
    注意:目录也是一种文件(所以也存在对应的inode)。打开目录,实际上就是打开目录文件。

    一个有效的dentry结构必定有一个inode结构,这是因为一个目录项要么代表着一个文件,要么代表着一个目录,而目录实际上也是文件。所以,只要dentry结构是有效的,则其指针d_inode必定指向一个inode结构。可是,反过来则不然,一个inode却可能对应着不止一个dentry结构;也就是说,一个文件可以有不止一个文件名或路径名。这是因为一个已经建立的文件可以被连接(link)到其他文件名。所以在inode结构中有一个队列i_dentry,凡是代表着同一个文件的所有目录项都通过其dentry结构中的d_alias域挂入相应inode结构中的i_dentry队列。

    在内核中有一个哈希表dentry_hashtable ,是一个list_head的指针数组。一旦在内存中建立起一个目录节点的dentry 结构,该dentry结构就通过其d_hash域链入哈希表中的某个队列中。

    内核中还有一个队列dentry_unused,凡是已经没有用户(count域为0)使用的dentry结构就通过其d_lru域挂入这个队列。

    Dentry结构中除了d_alias 、d_hash、d_lru三个队列外,还有d_vfsmnt、d_child及d_subdir三个队列。其中d_vfsmnt仅在该dentry为一个安装点时才使用。另外,当该目录节点有父目录时,则其dentry结构就通过d_child挂入其父节点的d_subdirs队列中,同时又通过指针d_parent指向其父目录的dentry结构,而它自己各个子目录的dentry结构则挂在其d_subdirs域指向的队列中。

    从上面的叙述可以看出,一个文件系统中所有目录项结构或组织为一个哈希表,或组织为一颗树,或按照某种需要组织为一个链表,这将为文件访问和文件路径搜索奠定下良好的基础。

    struct dentry {
       
        unsigned int d_flags;       
        seqcount_t d_seq;       
        struct hlist_bl_node d_hash;    
        struct dentry *d_parent;   
        struct qstr d_name;
        struct inode *d_inode;       
                        
        unsigned char d_iname[DNAME_INLINE_LEN];   
    
        /* Ref lookup also touches following */
    
        unsigned int d_count;   引用计数    
        spinlock_t d_lock;       
        const struct dentry_operations *d_op;
        struct super_block *d_sb;    
        unsigned long d_time;       
        void *d_fsdata;           
    
        struct list_head d_lru;    
       
        /*
         * d_child and d_rcu can share memory
         */
        union {
            struct list_head d_child;    /* child of parent list */
             struct rcu_head d_rcu;
        } d_u;
        struct list_head d_subdirs;    /* our children */
        struct list_head d_alias;    /* inode alias list */
    };
    
    d_count:引用计数
    
    d_flags:目录项缓存标识,可取DCACHE_UNUSED、DCACHE_REFERENCED等
    
    d_inode:与该目录项关联的inode
    
    d_parent:父目录的目录项
    
    d_hash:内核使用dentry_hashtable对dentry进行管理,dentry_hashtable是由list_head组成的链表,一个dentry创建之后,就通过
    
    d_hash链接进入对应的hash值的链表中。
    
    d_lru:最近未使用的目录项的链表
    
    d_child:目录项通过这个加入到父目录的d_subdirs中
    
    d_subdirs:本目录的所有孩子目录链表头
    d_alias:一个有效的dentry必然与一个inode关联,但是一个inode可以对应多个dentry,因为一个文件可以被链接到其他文件,所以,这个dentry就是通过这个字段链接到属于自己的inode结构中的i_dentry链表中的。(inode中讲过)
    
    d_mounted:安装在该目录的文件系统的数量!注意一个文件目录下可以有不同的文件系统!
    
    d_name:目录项名称
    
    d_time:重新变为有效的时间!注意只要操作成功这个dentry就是有效的,否则无效。
    
    d_op:目录项操作
    
    d_sb:这个目录项所属的文件系统的超级块
    
    d_vfs_flags:一些标志
    
    d_fsdata:文件系统私有数据
    
    d_iname:存放短的文件名
    
    struct dentry {
    
        atomic_t d_count;                     //目录项对象使用计数器,可以有未使用态,使用态和负状态 
        unsigned int d_flags;                  //目录项标志 
        struct inode *d_inode;                 //与文件名关联的索引节点 
        struct dentry *d_parent;               //父目录的目录项对象 
        struct list_head d_hash;               //散列表表项的指针 
        struct list_head d_lru;                 //未使用链表的指针 
        struct list_head d_child;               //父目录中目录项对象的链表的指针 
        struct list_head d_subdirs;             //对目录而言,表示子目录目录项对象的链表 
        struct list_head d_alias;               //相关索引节点(别名)的链表 
        int d_mounted;                          //对于安装点而言,表示被安装文件系统根项 
        struct qstr d_name;                     //文件名 
        unsigned long d_time;         /* used by d_revalidate */ 
        struct dentry_operations *d_op;         //目录项方法 
        struct super_block *d_sb;               //文件的超级块对象 
        vunsigned long d_vfs_flags; 
        void *d_fsdata;                         //与文件系统相关的数据 
        unsigned char d_iname [DNAME_INLINE_LEN]; //存放短文件名
    };

    3  file简介(文件记录表)

    文件对象表示进程已打开的文件,该对象file(不是物理文件)由相应的open()系统调用创建,有close()系统调用销毁,因为多个进程可以同时打开和操作一个文件,所以同一个文件也可能存在多个对应的文件对象。文件对象仅仅在进程观点上代表已打开文件,它反过来指向目录项对象(反过来指向索引节点),其实只有目录项对象才表示已打开的实际文件,虽然一个文件对应的文件对象不是是唯一的,但对应的索引节点和目录项对象无疑是唯一的,另外类似于目录项对象,文件对象实际上没有对应的磁盘数据。

     

    一个文件对象是由一个文件结构体表示的,文件结构体代表一个打开的文件,系统中的每个打开的文件在内核空间都有一个关联的 struct file。它由内核在打开文件时创建,并传递给在文件上进行操作的任何函数。在文件的所有实例都关闭后,内核释放这个数据结构。

     

    struct file { 
    union { struct list_head fu_list; //文件对象链表指针linux/include/linux/list.h struct rcu_head fu_rcuhead; //RCU(Read-Copy Update)是Linux 2.6内核中新的锁机制 }
     f_u; struct path f_path; //包含dentry和mnt两个成员,用于确定文件路径
    
     #define f_dentry f_path.dentry //f_path的成员之一,当前文件的dentry结构 
    #define f_vfsmnt f_path.mnt //表示当前文件所在文件系统的挂载根目录 
    const struct file_operations *f_op; //与该文件相关联的操作函数 
    atomic_t f_count; //文件的引用计数(有多少进程打开该文件) 
    unsigned int f_flags; //对应于open时指定的
    flag mode_t f_mode; //读写模式:open的mod_t mode参数 
    off_t f_pos; //该文件在当前进程中的文件偏移量 
    struct fown_struct f_owner; //该结构的作用是通过信号进行I/O时间通知的数据。 
    unsigned int f_uid, f_gid; //文件所有者id,所有者组id 
    struct file_ra_state f_ra; //在linux/include/linux/fs.h中定义,文件预读相关 
    unsigned long f_version; //记录文件的版本号,每次使用后都自动递增。 
    #ifdef 
    CONFIG_SECURITY void *f_security; //用来描述安全措施或者是记录与安全有关的信息。 
    #endif /* needed for tty driver, and maybe others */ 
    void *private_data; //可以用字段指向已分配的数据 
    #ifdef CONFIG_EPOLL /* Used by fs/eventpoll.c to link all the hooks to this file */ 
    struct list_head f_ep_links; 文件的事件轮询等待者链表的头, 
    spinlock_t f_ep_lock; 
    f_ep_lock是保护f_ep_links链表的自旋锁。 
    #endif /* #ifdef CONFIG_EPOLL */ 
    struct address_space *f_mapping; 文件地址空间的指针}; 

    4  files_struct简介

    struct files_struct { 
    
    atomic_t count;         /* 共享该表的进程数 */ 
    rwlock_t file_lock;     /* 保护该结构体的锁*/ 
    int max_fds;          /*当前文件对象的最大数*/
     int max_fdset;         /*当前文件描述符的最大数*/ 
    int next_fd;           /*已分配的文件描述符加1*/
     struct file ** fd;     /* 指向文件对象指针数组的指针 */ 
    fd_set *close_on_exec;        /*指向执行exec()时需要关闭的文件描述符*/
     fd_set *open_fds;          /*指向打开文件描述符的指针*/ 
    fd_set close_on_exec_init;      /* 执行exec()时关闭的初始文件*/ 
    fd_set open_fds_init;           /*文件描述符的初值集合*/ 
    struct file * fd_array[32];     /* 文件对象指针的初始化数组*/}; 

    fd域指向文件对象的指针数组。该数组的长度存放在max_fds域中。通常,fd域指向files_struct结构的fd_array域,该域包括32个文件对象指针。如果进程打开的文件数目多于32,内核就分配一个新的、更大的文件指针数组,并将其地址存放在fd域中;内核同时也更新max_fds域的值。

    对于在fd数组中有入口地址的每个文件来说,数组的索引就是文件描述符(file descriptor)。通常,数组的第一个元素(索引为0)是进程的标准输入文件,数组的第二个元素(索引为1)是进程的标准输出文件,数组的第三个元素(索引为2)是进程的标准错误文件。请注意,借助于dup()、dup2()和
    fcntl ) 系统调用,两个文件描述符就可以指向同一个打开的文件,也就是说,数组的两个元素可能指向同一个文件对象。当用户使用shell结构(如2>&;1)将标准错误文件重定向到标准输出文件上时,用户总能看到这一点。

    open_fds域包含open_fds_init域的地址,open_fds_init域表示当前已打开文件的文件描述符的位图。max_fdset域存放位图中的位数。由于数据结构fd_set有1024位,通常不需要扩大位图的大小。不过,如果确实必须的话,内核仍能动态增加位图的大小,这非常类似文件对象的数组的情形。

    当开始使用一个文件对象时调用内核提供的fget()函数。这个函数接收文件描述符fd作为参数,返回在current->files->fd[fd]中的地址,即对应文件对象的地址,如果没有任何文件与fd对应,则返回NULL。在第一种情况下,fget()使文件对象引用计数器f_count的值增1。

    用户打开文件表files_structs是由进程描述符task_struct中的file域指向,所有与进程相关的信息如打开的文件及文件描述符都包含其中,又从前面可以看出,files_struct通过**file保持对文件对象file的访问,于此相似文件对象file的结构体内成员中包含目录项dentry,目录项dentry将文件名与inode相连,最终通过inode中的指针可以访问存储实际的数据的地方Data Area.

    so他们管理层次关系关系如下:进程->task_struct->files_struct->file->dentry->inode->Data Area

    展开全文
  • ceph对象存储生态文件系统

    千次阅读 2013-12-05 11:30:06
    Ceph 最近才加入到 Linux 中令人印象深刻的文件系统备选行列,它是一个分布式文件系统,能够在维护 POSIX 兼容性的同时加入了复制和容错功能。探索 Ceph 的架构,学习它如何提供容错功能,简化海量数据管理。 0 ...
    

    Linux®持续不断进军可扩展计算空间,特别是可扩展存储空间。Ceph 最近才加入到 Linux 中令人印象深刻的文件系统备选行列,它是一个分布式文件系统,能够在维护 POSIX 兼容性的同时加入了复制和容错功能。探索 Ceph 的架构,学习它如何提供容错功能,简化海量数据管理。

    M. Tim Jones, 自由作家

    M. Tim JonesM. Tim Jones 是一名嵌入式固件架构师,他还是Artificial Intelligence:A Systems Approach,GNU/Linux Application Programming(第二版),AI Application Programming(第二版),以及BSD Sockets Programming from a Multilanguage Perspective 这几本书的作者。他的工程背景非常广泛,从同步宇宙飞船的内核开发到嵌入式系统架构设计,再到网络协议的开发。Tim 是位于科罗拉多州 Longmont 的 Emulex Corp. 的一名顾问工程师。



    2010 年 6 月 12 日

    联系 Tim

    Tim 是最受欢迎,作品最多的四位作者之一。浏览 developerWorks 上 Tim 的所有文章。查看 Tim 的个人简介,联系他和其他作者,以及在 My developerWorks 中的其他读者。

    作为一名存储行业的架构师,我对文件系统情有独钟。这些系统用来存储系统的用户界面,虽然它们倾向于提供一系列类似的功能,但它们还能够提供差异显著的功能。Ceph 也不例外,它还提供一些您能在文件系统中找到的最有趣的功能。

    Ceph 最初是一项关于存储系统的 PhD 研究项目,由 Sage Weil 在 University of California, Santa Cruz(UCSC)实施。但是到了 2010 年 3 月底,您可以在主线 Linux 内核(从 2.6.34 版开始)中找到 Ceph 的身影。虽然 Ceph 可能还不适用于生产环境,但它对测试目的还是非常有用的。本文探讨了 Ceph 文件系统及其独有的功能,这些功能让它成为可扩展分布式存储的最有吸引力的备选。

    Ceph 目标

    为什么选 “Ceph”?

    “Ceph” 对一个文件系统来说是个奇怪的名字,它打破了大多数人遵循的典型缩写趋势。这个名字和 UCSC(Ceph 的诞生地)的吉祥物有关,这个吉祥物是 “Sammy”,一个香蕉色的蛞蝓,就是头足类中无壳的软体动物。这些有多触角的头足类动物,提供了一个分布式文件系统的最形象比喻。

    开发一个分布式文件系统需要多方努力,但是如果能准确地解决问题,它就是无价的。Ceph 的目标简单地定义为:

    • 可轻松扩展到数 PB 容量
    • 对多种工作负载的高性能(每秒输入/输出操作[IOPS]和带宽)
    • 高可靠性

    不幸的是,这些目标之间会互相竞争(例如,可扩展性会降低或者抑制性能或者影响可靠性)。Ceph 开发了一些非常有趣的概念(例如,动态元数据分区,数据分布和复制),这些概念在本文中只进行简短地探讨。Ceph 的设计还包括保护单一点故障的容错功能,它假设大规模(PB 级存储)存储故障是常见现象而不是例外情况。最后,它的设计并没有假设某种特殊工作负载,但是包括适应变化的工作负载,提供最佳性能的能力。它利用 POSIX 的兼容性完成所有这些任务,允许它对当前依赖 POSIX 语义(通过以 Ceph 为目标的改进)的应用进行透明的部署。最后,Ceph 是开源分布式存储,也是主线 Linux 内核(2.6.34)的一部分。


    Ceph 架构

    现在,让我们探讨一下 Ceph 的架构以及高端的核心要素。然后我会拓展到另一层次,说明 Ceph 中一些关键的方面,提供更详细的探讨。

    Ceph 生态系统可以大致划分为四部分(见图 1):客户端(数据用户),元数据服务器(缓存和同步分布式元数据),一个对象存储集群(将数据和元数据作为对象存储,执行其他关键职能),以及最后的集群监视器(执行监视功能)。

    图 1. Ceph 生态系统的概念架构
    概念流程图显示 Ceph 生态系统的架构:客户端,元数据服务器集群,对象存储集群,集群监视器

    如图 1 所示,客户使用元数据服务器,执行元数据操作(来确定数据位置)。元数据服务器管理数据位置,以及在何处存储新数据。值得注意的是,元数据存储在一个存储集群(标为 “元数据 I/O”)。实际的文件 I/O 发生在客户和对象存储集群之间。这样一来,更高层次的 POSIX 功能(例如,打开、关闭、重命名)就由元数据服务器管理,不过 POSIX 功能(例如读和写)则直接由对象存储集群管理。

    另一个架构视图由图 2 提供。一系列服务器通过一个客户界面访问 Ceph 生态系统,这就明白了元数据服务器和对象级存储器之间的关系。分布式存储系统可以在一些层中查看,包括一个存储设备的格式(Extent and B-tree-based Object File System [EBOFS] 或者一个备选),还有一个设计用于管理数据复制,故障检测,恢复,以及随后的数据迁移的覆盖管理层,叫做Reliable Autonomic Distributed Object Storage(RADOS)。最后,监视器用于识别组件故障,包括随后的通知。

    图 2. Ceph 生态系统简化后的分层视图
    块状图显示一个 Ceph 生态系统简化后的分层视图,包括服务器,元数据服务器,以及对象存储 ddaemon

    Ceph 组件

    了解了 Ceph 的概念架构之后,您可以挖掘到另一个层次,了解在 Ceph 中实现的主要组件。Ceph 和传统的文件系统之间的重要差异之一就是,它将智能都用在了生态环境而不是文件系统本身。

    图 3 显示了一个简单的 Ceph 生态系统。Ceph Client 是 Ceph 文件系统的用户。Ceph Metadata Daemon 提供了元数据服务器,而 Ceph Object Storage Daemon 提供了实际存储(对数据和元数据两者)。最后,Ceph Monitor 提供了集群管理。要注意的是,Ceph 客户,对象存储端点,元数据服务器(根据文件系统的容量)可以有许多,而且至少有一对冗余的监视器。那么,这个文件系统是如何分布的呢?

    图 3. 简单的 Ceph 生态系统
    一个简单 Ceph 生态系统的块状图

    Ceph 客户端

    内核或用户空间

    早期版本的 Ceph 利用在 User SpacE(FUSE)的 Filesystems,它把文件系统推入到用户空间,还可以很大程度上简化其开发。但是今天,Ceph 已经被集成到主线内核,使其更快速,因为用户空间上下文交换机对文件系统 I/O 已经不再需要。

    因为 Linux 显示文件系统的一个公共界面(通过虚拟文件系统交换机 [VFS]),Ceph 的用户透视图就是透明的。管理员的透视图肯定是不同的,考虑到很多服务器会包含存储系统这一潜在因素(要查看更多创建 Ceph 集群的信息,见参考资料 部分)。从用户的角度看,他们访问大容量的存储系统,却不知道下面聚合成一个大容量的存储池的元数据服务器,监视器,还有独立的对象存储设备。用户只是简单地看到一个安装点,在这点上可以执行标准文件 I/O。

    Ceph 文件系统 — 或者至少是客户端接口 — 在 Linux 内核中实现。值得注意的是,在大多数文件系统中,所有的控制和智能在内核的文件系统源本身中执行。但是,在 Ceph 中,文件系统的智能分布在节点上,这简化了客户端接口,并为 Ceph 提供了大规模(甚至动态)扩展能力。

    Ceph 使用一个有趣的备选,而不是依赖分配列表(将磁盘上的块映射到指定文件的元数据)。Linux 透视图中的一个文件会分配到一个来自元数据服务器的 inode number(INO),对于文件这是一个唯一的标识符。然后文件被推入一些对象中(根据文件的大小)。使用 INO 和 object number(ONO),每个对象都分配到一个对象 ID(OID)。在 OID 上使用一个简单的哈希,每个对象都被分配到一个放置组。放置组(标识为 PGID)是一个对象的概念容器。最后,放置组到对象存储设备的映射是一个伪随机映射,使用一个叫做Controlled Replication Under Scalable Hashing(CRUSH)的算法。这样一来,放置组(以及副本)到存储设备的映射就不用依赖任何元数据,而是依赖一个伪随机的映射函数。这种操作是理想的,因为它把存储的开销最小化,简化了分配和数据查询。

    分配的最后组件是集群映射。集群映射 是设备的有效表示,显示了存储集群。有了 PGID 和集群映射,您就可以定位任何对象。

    Ceph 元数据服务器

    元数据服务器(cmds)的工作就是管理文件系统的名称空间。虽然元数据和数据两者都存储在对象存储集群,但两者分别管理,支持可扩展性。事实上,元数据在一个元数据服务器集群上被进一步拆分,元数据服务器能够自适应地复制和分配名称空间,避免出现热点。如图 4 所示,元数据服务器管理名称空间部分,可以(为冗余和性能)进行重叠。元数据服务器到名称空间的映射在 Ceph 中使用动态子树逻辑分区执行,它允许 Ceph 对变化的工作负载进行调整(在元数据服务器之间迁移名称空间)同时保留性能的位置。

    图 4. 元数据服务器的 Ceph 名称空间的分区
    图表显示元数据服务器的 Ceph 名称空间的分区

    但是因为每个元数据服务器只是简单地管理客户端人口的名称空间,它的主要应用就是一个智能元数据缓存(因为实际的元数据最终存储在对象存储集群中)。进行写操作的元数据被缓存在一个短期的日志中,它最终还是被推入物理存储器中。这个动作允许元数据服务器将最近的元数据回馈给客户(这在元数据操作中很常见)。这个日志对故障恢复也很有用:如果元数据服务器发生故障,它的日志就会被重放,保证元数据安全存储在磁盘上。

    元数据服务器管理 inode 空间,将文件名转变为元数据。元数据服务器将文件名转变为索引节点,文件大小,和 Ceph 客户端用于文件 I/O 的分段数据(布局)。

    Ceph 监视器

    Ceph 包含实施集群映射管理的监视器,但是故障管理的一些要素是在对象存储本身中执行的。当对象存储设备发生故障或者新设备添加时,监视器就检测和维护一个有效的集群映射。这个功能按一种分布的方式执行,这种方式中映射升级可以和当前的流量通信。Ceph 使用 Paxos,它是一系列分布式共识算法。

    Ceph 对象存储

    和传统的对象存储类似,Ceph 存储节点不仅包括存储,还包括智能。传统的驱动是只响应来自启动者的命令的简单目标。但是对象存储设备是智能设备,它能作为目标和启动者,支持与其他对象存储设备的通信和合作。

    从存储角度来看,Ceph 对象存储设备执行从对象到块的映射(在客户端的文件系统层中常常执行的任务)。这个动作允许本地实体以最佳方式决定怎样存储一个对象。Ceph 的早期版本在一个名为EBOFS 的本地存储器上实现一个自定义低级文件系统。这个系统实现一个到底层存储的非标准接口,这个底层存储已针对对象语义和其他特性(例如对磁盘提交的异步通知)调优。今天,B-tree 文件系统(BTRFS)可以被用于存储节点,它已经实现了部分必要功能(例如嵌入式完整性)。

    因为 Ceph 客户实现 CRUSH,而且对磁盘上的文件映射块一无所知,下面的存储设备就能安全地管理对象到块的映射。这允许存储节点复制数据(当发现一个设备出现故障时)。分配故障恢复也允许存储系统扩展,因为故障检测和恢复跨生态系统分配。Ceph 称其为 RADOS(见图 3)。


    其他有趣功能

    如果文件系统的动态和自适应特性不够,Ceph 还执行一些用户可视的有趣功能。用户可以创建快照,例如,在 Ceph 的任何子目录上(包括所有内容)。文件和容量计算可以在子目录级别上执行,它报告一个给定子目录(以及其包含的内容)的存储大小和文件数量。


    Ceph 的地位和未来

    虽然 Ceph 现在被集成在主线 Linux 内核中,但只是标识为实验性的。在这种状态下的文件系统对测试是有用的,但是对生产环境没有做好准备。但是考虑到 Ceph 加入到 Linux 内核的行列,还有其创建人想继续研发的动机,不久之后它应该就能用于解决您的海量存储需要了。


    其他分布式文件系统

    Ceph 在分布式文件系统空间中并不是唯一的,但它在管理大容量存储生态环境的方法上是独一无二的。分布式文件系统的其他例子包括 Google File System(GFS),General Parallel File System(GPFS),还有 Lustre,这只提到了一部分。Ceph 背后的想法为分布式文件系统提供了一个有趣的未来,因为海量级别存储导致了海量存储问题的唯一挑战。


    展望未来

    Ceph 不只是一个文件系统,还是一个有企业级功能的对象存储生态环境。在 参考资料 部分中,您将会找到如何设置一个简单 Ceph 集群(包括元数据服务器,对象存储服务器和监视器)的信息。Ceph 填补了分布式存储中的空白,看到这个开源产品如何在未来演变也将会是很有趣的。

    参考资料

    学习

    获得产品和技术

    讨论

    • 加入 My developerWorks 社区。查看开发人员推动的博客、论坛、组和 wikis,并与其他 developerWorks 用户交流。
    展开全文
  • 提供了两个方法来删除文件系统中的对象,使用哪一个方法取决于具体的类型。要删除一个空目录,可以使用rmdir()。 import pathlib p = pathlib.Path('example_dir') print('Removing {}'.format(p)) p.rmdir() ...
  • 所谓文件系统的本质是POSIX接口,“对象”这个名词是做对象存储的人为了把自己做的东西和文件系统区分开而用的术语,把存在对象存储里的文件叫做“对象”,所以选择文件系统还是对象存储,跟你把这堆数据称作对象...
  • 8.1 pathlib--面向对象设计的文件系统路径本模块主要提供了不同操作系统下的文件系统路径的操作方式。路径类分为纯路径操作无I/O操作的类和有I/O操作相关的类。整个路径的继承关系图如下:如果从来没有使用过本模块...
  • 一 .VFS 中的目录项对象 1.为了方便查找,VFS引入了 目录 项,每个...2.目录项对象由dentry结构体表示 ,定义在文件linux/dcache.h 头文件中。  89struct dentry {  90 atomic_t d_count; //使用计数  91
  • 想实现的功能如下:参数配置对象转换成json字符串保存到文件系统, 从文件系统读取字符串转换成json对象。 CreateTextFile(FileName, Overwrite, Unicode) OpenTextFile(FileName, IOMode, Create, Format)var fso...
  • Linux 内核编程之文件系统(二) 几个关系: (1)inode索引节点表示文件的信息——每个文件都有一个inode。 (2)dentry目录项表示文件名与inode的对应关系。 (3)一个inode可能对应不止一个dentry结构。 ...
  • 文件对象文件系统设备、卷设备之间的关系简单说明 http://hi.baidu.com/jonathan2004/item/cb7fd9406301deac60d7b95d 本文档的CopyRight归jonathan所有,可自由转载,转载时请保持文档的完整性。 ...
  • 文件对象文件映射对象 转载自:https://blog.csdn.net/sunnymov/article/details/5410449 1.内存映射文件   内存映射文件与虚拟内存有些类似,通过内存映射文件可以保留一个地址空间的区域,同时将物理存储器...
  • 文件系统中主要对象:●超级块(superblock)对象: 存放系统中已安装文件系统的有关信息。对于基于磁盘的文件系统(具有I/O操作),这类对象通常对应于存放在磁盘上的文件系统控制块(FCB),也就是说,每个文件系统...
  • http://www.testlab.com.cn/Index/article/id/1082.html 摘要:对象存储和我们经常接触到的硬盘和文件系统等存储形态不同,它提供Key-Value(简称K/V)方式的RESTful数据读写接口,并且常以网络服务的形式提供数据...
  • 对象存储、块存储、文件系统存储概念与区别 https://www.cnblogs.com/zxiner/p/7141861.html 一、概念及区别 针对不同的应用场景,选择的分布式存储方案也会不同,因此有了对象存储、块存储、文件系统存储。这三...
  • 认识 VB 的文件系统对象 FSO

    千次阅读 2004-03-15 09:17:00
    在VB 推出文件系统对象(File System Object)以前,完成这些功能需要调用 Windows API 函数或者使用一些比较复杂的过程来实现,使编程复杂、可靠性差又容易出错。使用 Windows 提供的的文件系统对象,一切变得简单多...
  • Ceph 是一个开源的分布式存储系统,包括对象存储、块设备、文件系统。它可靠性高、管理方便、伸缩性强,能够轻松应对PB、EB级别数据。Ceph 存储体系中,核心为 RADOS,它是一个高可用分布式对象存储,该模块负责对...
  • 利用HDFS的JAVA API进行使用,完成获取系统文件对象、读取文件内容、上传文件三部分内容。 准备工作: 1.首先启动HDFS $HADOOP_HOME/sbin/start-dfs.sh 2.关防火墙 切换到root用户,执行service iptables stop...
  • 最近在Quora上有人提到一个问题,有关Hadoop分布式文件系统和OpenStack对象存储的不同。  问题原文如下:  “HDFS (Hadoop分布式文件系统)和OpenStack对象存储(OpenStack Object Storage)似乎都有着相似的...
  • 1.引言 本文所述关于文件管理的系列文章主要是对陈莉君老师所讲述的文件系统管理知识讲座的整理。...Linux文件系统1--概述 中我们了解了文件系统的作用,以及为了使得所有的文件系统能在同一个操...
  • Ceph 是一个开源的分布式存储系统,包括对象存储、块设备、文件系统。它可靠性高、管理方便、伸缩性强,能够轻松应对 PB、EB 级别数据。Rook 是专用于 Cloud-Native 环境的文件、块、对象存储服务。它实现了一个自动...
  • 文件对象文件映射对象

    千次阅读 2010-03-24 09:11:00
    文件对象文件映射对象(问题来源:IPP例子simple_player vm_mmap _win32.c文件中的vm_mmap_create函数)1.内存映射文件 内存映射文件与虚拟内存有些类似,通过内存映射文件可以保留一个地址空间的区域,同时将...
  • 最近在Quora上有人提到一个问题,有关Hadoop分布式文件系统和OpenStack对象存储的不同。 问题原文如下:“HDFS (Hadoop分布式文件系统)和OpenStack对象存储(OpenStack Object Storage)似乎都有着相似的目的:实现...
  • 在VB 推出文件系统对象(File System Object)以前,完成这些功能需要调用 Windows API 函数或者使用一些比较复杂的过程来实现,使编程复杂、可靠性差又容易出错。使用 Windows 提供的的文件系统对象,一切变得简单多...
  • VFS的面向对象的思想,如下图: VFS在上层用户空间的进程与底层特定文件系统之间起到一个承上启下的作用, ...对下:抽象出标准的开发接口给真实文件系统,只要实现这些接口,就可以实现一个新的真实文件系统

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 35,899
精华内容 14,359
热门标签
关键字:

对象文件系统