ceph 的 bufferlist

【ceph 的 bufferlist】的更多相关文章

Ceph中Bufferlist的设计与使用

转自:https://www.ustack.com/blog/bufferlist/ 如果非要在整个Ceph中,找出一个类最重要,我觉得非Bufferlist莫属了,原因很简单,因为Bufferlist负责管理Ceph中所有的内存.整个Ceph中所有涉及到内存的操作,无论是msg分配内存接收消息,还是OSD构造各类数据结构的持久化表示(encode/decode),再到实际磁盘操作,都将bufferlist作为基础. Ceph中bufferlist的设计还是有些复杂的,其中包含三个主要的内buf…

bufferlist是buffer::list的别名,其由来在 http://bean-li.github.io/bufferlist-in-ceph/ 中有非常详细的介绍其p.p_off.off字段的含义可以通过advance(int o)函数来理解简单来说,p就说指向_buffer的迭代器,p_off则是在当前buffer::ptr的_raw中的偏移,而off则是把_buffer中的_raw视为一个整体时的当前偏移.如下图中,o为1000时,则p为ptr3,p_off为200(由1000…

Ceph中的序列化

转自:https://www.ustack.com/blog/cephxuliehua/ 作为主要和磁盘.网络打交道的分布式存储系统,序列化是最基础的功能之一,今天我们来看一下Ceph中序列化的设计与实现. 1 Ceph序列化的方式序列化(ceph称之为encode)的目的是将数据结构表示为二进制流的方式,以便通过网络传输或保存在磁盘等存储介质上,其逆过程称之为反序列化(ceph称之为decode). 例如对于字符串“abc”,其序列化结果为8个字节(bytes): 03 00 00…

Ceph剖析：Paxos算法实现

作者:吴香伟发表于 2014/10/8 版权声明:可以任意转载,转载时务必以超链接形式标明文章原始出处和作者信息以及版权声明 Recovery阶段在Leader选举成功后,Leader和Peon都进入Recovery阶段.该阶段的目的是为了保证新Quorum的所有成员状态一致,这些状态包括:最后一个批准(Committed)的提案,最后一个没批准的提案,最后一个接受(Acceppted)的提案.每个节点的这些状态都持久化到磁盘.对旧Quorum的所有成员来说,最后一个通过的提案应该都是相同的…

海量小文件存储与Ceph实践

海量小文件存储(简称LOSF,lots of small files)出现后,就一直是业界的难题,众多博文(如[1])对此问题进行了阐述与分析,许多互联网公司也针对自己的具体场景研发了自己的存储方案(如taobao开源的TFS,facebook自主研发的Haystack),还有一些公司在现有开源项目(如hbase,fastdfs,mfs等)基础上做针对性改造优化以满足业务存储需求: 一. 通过对若干分布式存储系统的调研.测试与使用,与其它分布式系统相比,海量小文件存储更侧重于解决两个问题: 1.…

CentOS6.3上部署Ceph

一.背景知识搭建ceph的机器分为两种:client和非client(mds.monitor.osd). 配置时client只需要在内核编译时选上ceph就行,而其它三种则还需要编译ceph用户态源码(下载地址:http://ceph.com/download/),另外osd还要记得安装btrfs文件系统(内核编译作为模块就行). 内核版本参考: http://ceph.com/docs/master/install/os-recommendations/#glibc 二.机器分配…

Ceph源码解析：读写流程

转载注明出处,整理也是需要功夫的,http://www.cnblogs.com/chenxianpao/p/5572859.html 一.OSD模块简介 1.1 消息封装:在OSD上发送和接收信息. cluster_messenger -与其它OSDs和monitors沟通 client_messenger -与客户端沟通 1.2 消息调度: Dispatcher类,主要负责消息分类 1.3 工作队列: 1.3.1 OpWQ: 处理ops(从客户端)和sub ops(从其他的OSD).运行在op…