1.cephfs集群搭建，源码在客户端挂载后，安装在这个挂载目录里，源码新建目录，安装存储数据，源码能限制目录的安装zn源码大小吗（配额）？
2.Cephfs 快照介绍与使用
3.Ceph为什么越来越火？国内使用ceph较为成功的存储厂商有哪些？
4.cephfs：用户态客户端预读
5.GlusterFS和Ceph哪个好？

cephfs集群搭建，在客户端挂载后，源码在这个挂载目录里，安装新建目录，源码存储数据，安装能限制目录的源码大小吗（配额）？

       cephfs使用ceph-fuse的方式挂载可以设置配额，内核方式挂载暂时还不能设置配额，安装

       用户态ceph-fuse挂载设置配额的源码方式为：

       setfattr -n ceph.quota.max_bytes -v /dir/dir/

Cephfs 快照介绍与使用

        云和安全管理服务专家新钛云服 祝祥翻译

        CEPFS支持快照功能，通常通过使用mkdir命令创建快照目录。注意这是一个隐藏的特殊目录，在目录列表中不可见。

        通常情况下，快照正如起名：它们保存数据变化过程中的状态。需要注意的一点事，CEPFS快照的一些功能与您可能期望的有所不同：

        默认情况下，新文件系统上会启用CEPFS快照功能。要在现有文件系统上启用它，请使用下面的命令。

        启用快照后，CephFS中的所有目录都将有一个特殊的 .snap 快照目录。（如果愿意，可以使用客户端snapdir设置配置其他名称）

        要创建CephFS快照，请在 .snap 下创建子目录。用你选择的名字创建快照。例如，要在目录“/1/2/3/”下创建快照，请使用 mkdir /1/2/3/.snap/my-snapshot-name 命令。

        客户端会将请求发送到MDS服务器，然后在服务器的Server::handle_client_mksnap（）中处理。它会从 SnapServer中分配一个 snapid，利用新的 SnapRealm创建并链接一个新的inode，然后将其提交到 MDlog，提交后会触发 MDCache::do_realm_invalidate_and_update_notify()，此函数将此 SnapRealm广播给所有对快照目录下任一文件有管辖权的客户端。客户端收到通知后，将同步更新本地 SanpRealm层级结构，并为新的SnapRealm结构生成新的 SnapContext，用于将快照数据写入 OSD 端。同时，快照的元数据会作为目录信息的一部分更新到OSD端（即sr_t）。整个过程是完全异步处理的。

        如果删除快照，将执行类似的过程。如果将inode从其父SnapRealm中删除，重命名代码将为重命名的inode创建一个新的SnapRealm（如果SnapRealm不存在），将在原始父SnapRealm上有效的快照ID保存到新SnapRealm的父快照（past_parent_snaps）中，然后遵循与创建快照类似的过程。

        RADOS SnapContext由一个快照序列ID（snapid）和一个包含所有快照ID对象组成。为了生成该列表，我们将与SnapRealm关联的SnapID与父快照中的所有有效SnapID结合起来。过时的SnapID由SnapClient缓存的有效快照过滤掉。

        文件数据存储在RADOS“self-managed”快照中。在将文件数据写入OSD时，客户端会小心地使用正确的SnapContext。

        快照的dentries（及其inode）作为快照时所在目录的一部分在线存储。所有dentries都包括第一个和最后一个有效的snapid。（非快照的dentries将最后设置为CEPH_NOSNAP）。

        有大量代码可以有效地处理写回。当客户端收到MClientSnap消息时，它会更新本地SnapRealm表示及其到特定Inode的链接，并为Inode生成CapSnap。CapSnap作为功能写回的一部分被清除，如果存在脏数据，CapSnap将用于阻止新的数据写入，直到快照完全清除到OSD。 在MDS中，我们生成代表牙齿的快照，作为冲洗牙齿的常规过程的一部分。具有杰出CapSnap数据的假牙被固定并记录在日志中。

        通过在快照的根目录“.snap”中调用“rmdir”来删除快照。（尝试删除根快照将失败的目录；必须先删除快照。）一旦删除，它们将被输入到已删除快照的OSDMap列表中，文件数据将由OSD删除。当目录对象被读入并再次写回时，元数据会被清除。

        具有多个硬链接的Inode被移动到一个虚拟全局SnapRealm。虚拟SnapRealm覆盖文件系统中的所有快照。inode的数据将为任何新快照保留。这些保留的数据将覆盖inode的任何链接上的快照。

        需要注意的是，CephFS的快照和多个文件系统的交互是存在问题的——每个 MDS集群独立分配 snappid，如果多个文件系统共享一个池，快照会冲突。如果此时有客户删除一个快照，将会导致其他人丢失数据，并且这种情况不会提升异常，这也是 CephFS的快照不推荐使用的原因之一。

        创建快照：

        从快照中恢复文件：

        自动快照

        使用cephfs-snap自动创建和删除旧快照。

        下载文件到 /usr/bin

        配合cron 一起使用。{ hourly,daily,weekly,monthly}

        使用示例：

        创建的 cron 文件必须设置为可执行

        要验证配置的 cron 任务是否会正确执行，请手动运行上述步骤中创建的 cron.* 脚本

        现在检查 .snap 目录中是否创建了 cephfs 快照

        如果 cron 没有按预期触发快照，请验证“/usr/bin/cephfs-snap”和“/etc/cron.*/cephfs-snap”文件是否可执行

        参考文章：

Ceph为什么越来越火？国内使用ceph较为成功的存储厂商有哪些？

       Ceph是当前非常流行的开源分布式存储系统，具有高扩展性、安装高性能、源码高可靠性等优点，同时提供块存储服务(rbd)、对接360影视源码对象存储服务(rgw)以及文件系统存储服务(cephfs)。目前也是OpenStack的主流后端存储，随着OpenStack在云计算领域的广泛使用，ceph也变得更加炙手可热。国内目前使用ceph搭建分布式存储系统较为成功的企业有x-sky,深圳元核云，上海UCloud等三家企业。

cephfs：用户态客户端预读

       用户态客户端读取文件数据通常通过Client::_read_async函数实现，这是read操作的核心函数。根据名称，“异步读”意味着存在与之对应的“同步读”，即Client::_read_sync。理解了Client::_read_async，Client::_read_sync也就容易掌握了。这两者之间的主要区别在于，Client::_read_async负责读取缓存并具有预读功能，而Client::_read_sync则是tomato源码编辑出错直接从osd读取数据。

       Client::_read_async可以简单分为read和readahead两部分。read对应于读流，而readahead对应于预读流。以下是这两个流的简单图示。可以看出，readahead stream不会阻塞等待。

       结合代码来解释Client::_read_async。首先，解释一下预读。假设我们读取一个M的文件，每次读取k，如果没有预读且最初没有缓存文件内容，总共需要读取次，每次都需要与osd交互。如果有预读，同样需要读取次，impala源码几种语言但每次发送k的读请求给osd后，预读机制会再发送一个k的读请求，后面的k的读请求不阻塞等待。这相当于将用户的一次读请求在后端分成两个请求，共读取k，其中后一个k的请求是异步的。因此，下一次读请求来时，增加了命中缓存的几率，即使没有命中缓存，这也相当于提前将这个k的请求发送给osd，争取了一点时间效率。

       预读Readahead在ceph中可以作为一个单独的模块，其代码位置在src/common/Readahead.h和src/common/Readahead.cc。这个模块的功能很简单，即通过简单的查询单页源码机制或算法来计算每次预读的偏移（offset）和长度（length）。

       在Readahead类中，有两个参数m_readahead_min_bytes和m_readahead_max_bytes，表示预读请求的最小和最大预读长度。这两个值是通过配置参数赋值的，在src/common/options.cc中有三个关于预读的配置参数。m_readahead_min_bytes和m_readahead_max_bytes的赋值位置在Client::_create_fh处。

       从上面的代码中可以看出，m_readahead_min_bytes的值为 * = KB，m_readahead_max_bytes的值为in->layout.get_period() * (uint_t)conf->client_readahead_max_periods。get_period()函数来自结构体file_layout_t。目前ceph中使用的是简单条带策略，stripe_unit = object_size = 4M，stripe_count = 1，因此m_readahead_max_bytes的值为4M * 4 = M。综上所述，预读的范围是KB ~ M（在不考虑预读对齐的情况下）。

       Readahead类实例是作为struct Fh的成员来使用的，struct Fh可以看作是文件的描述结构，Fh即File handle的简写。

       读取文件时，需要先打开文件，在打开文件时，会建立Fh，并将其加入fd_map中。然后在关闭文件时，销毁Fh，并将其从fd_map中移除。代码如下：先是Client::open，然后再Client::_open中调用Client::_create_fh创建Fh。可以看出，如果一个文件已经打开，修改的预读范围对正在读取的文件是没有影响的。

       在Client::_read_async中，在进行预读之前，需要计算预读的偏移值和长度。readahead_extent.first是偏移值，readahead_extent.second是长度，通过Readahead::update函数得到。

       Readahead::update代码如下。在研究Readahead::_observe_read代码之前，先研究Readahead中7个比较重要的参数。Readahead::_observe_read代码如下。从代码中可以看出，_observe_read函数的作用是判断这一次的读请求是否是顺序的，如果不是顺序读，将其中的5个成员置0（置0的作用在后面可以看到，最后算出的预读偏移和长度都为0）。

       Readahead::_compute_readahead是预读最重要的函数，代码如下。单纯看代码，会有点看不懂预读对齐，参考下面的图，更容易理解。上面的原理图只画了一种情况，即offset和offset+len分别落在不同的对象区间。如果readahead_end靠近align_prev时，如果需要对齐到4n，那么对齐的代价就是减少的对齐长度不能大于对齐前的预读长度的一半；如果readahead_end更靠近align_next时，如果需要对齐到4(n+1)，那么对齐的代价就是增加的对齐长度不能大于对齐前的预读长度的一半。

       还有第二种情况，即offset和offset+len分别落在相同的对象区间。这个时候就不能往align_prev对齐，如果需要补全到align_next，同样的道理，补全的对齐长度不能大于对齐前的预读长度的一半。所以通过预读对齐，预读的大小范围在K到M。

       预读的原理图如下。预读的时候会判断是否是顺序读，这里就涉及到读的方式，一般都是顺序读，除非特意指定为随机读，当然这种情况暂且不论。在正常的顺序读中，也会出现非顺序读的情况。以ceph-fuse为例，比如读取M的test文件，一个io是K，总共会发个读请求。简单示意图如下。由于存储后端osd回复读请求的时间不一致，所以预读不一定按照①②③④顺序执行请求，假设①请求处理完后，③请求②请求比先读到后端数据，即顺序为①③②④。那么在处理③时，预读Readahead实例中记录的m_last_pos = K，而此时的读流的offset = K，m_last_pos != offset，这就没有按照顺序去读，就不会去预读。

GlusterFS和Ceph哪个好？

       GlusterFS和Ceph都是Red Hat旗下的成熟的开源存储产品，Ceph与GlusterFS在原理上有着本质上的不同。现在网上有很多GlusterFS和Ceph的对比文章，可以参考。总的来说，如果只使用文件协议，感觉GlusterFS好一些；如果要使用对象、块、文件统一存储，那Ceph是不二选择。要使用好这两个开源软件，都需要有一定的IT实力和投入，如果实际上生产使用，建议选择商业化的产品，GlusterFS商业产品做得比较好的公司有大道、凯翔，Ceph商业产品做得比较好的公司有XSKY、元核云、杉岩。