摘要： 原文：A Study on Data Deduplication in HPC Storage Systems.这是今年Super Computing上的文章，目的不是提出一种在数据中心去重的解决方案，而是分析数据中心的数据集，去指导未来的设计。作者似乎很喜欢写这类分析数据集文章，他在SYSTOR’09比较过备份环境下各级去重的效果。他开源了fs-c，这两篇文章的分析工具。这篇文章可以和微软、EMC的2篇文章进行比较，都是对数据集进行研究，但环境不一样，特点也不一样。文章的数据规模很大，达到1212TB，迄今为止最大的数据集，作者拿到了多个欧/美数据中心的数据。1.发现关于文件大小、文件后缀的 阅读全文

摘要： 最近实现了Assuring Demanded Read Performance of Data Deduplication Storage with Backup Datasets一文中提出的算法，并用两个数据集分别进行了实验。参数分别设为cfl_require=0.6，container_usage_threshold=0.7，同时装备大小为100个container的LRU缓存。1.linux源码集数据集包括105个连续的linux内核版本，总数据量为40.6GB。95%为重复数据，经过选择去重后，去重率下降到78%。使用cfl选择去重算法后，恢复性能如图所示。最初的几个作业能达到100M 阅读全文

摘要： Dremel是一个可扩展的、交互式即时查询系统，用于分析只读的嵌套数据。Dremel可以对集群上的超大数据集进行交互式分析。Pig、Hive利用MapReduce执行查询，需要在多个MR作业间传递数据，相比之下，Dremel是就地执行查询的（MapReduce的瓶颈很有可能就是在Map和Reduce之间传递数据）。Dremel并不是用来取代MapReduce的，它可以和MapReduce互相补充，比如用于分析MapReduce的输出。实现Dremel有2个问题：首先是通用的存储层，比如GFS，一个高性能的存储层对于就地查询是非常关键的；其次是存储格式，按列存储对于扁平的关系数据非常合适，运用到 阅读全文

摘要： 缓存替换算法有很多种，FIFO是最简单的，LRU是最常用的，最优缓存替换算法则是命中率最佳的。因为我们无法预知数据的未来访问模式，通常最优替换算法是无法实现的。然而数据恢复则是例外：在备份的过程中，我们已经知道数据恢复的顺序。既然如此，何不通过最优缓存替换算法进一步改善命中率。数据去重原型系统destor里面已经实现了LRU缓存，并且工作得还不错，尽管如此，我仍然想看看最优替换算法能获得怎样的效果。1.种子文件备份的过程中，我记录下container的访问顺序，称之为种子文件，每个种子代表访问一个container。种子文件会作为最优替换算法的输入。2.滑动窗口如果我们一次性读取整个种子文件， 阅读全文

摘要： FAST’12, iDedup: Latency-aware, inline data deduplication for primary storage.二级存储是重删技术的主要应用场景，少量主存储使用了离线重删技术。二级存储要求高吞吐率，主存储要求低延迟。下图是重删技术的分类，和iDedup所处的位置。0.介绍主存储环境下，在线重删最大的挑战是不能增加前台操作的延迟。但是，重删元数据的管理和访问会增加写延迟；碎片导致逻辑连续读被拆分为随机IO增加读延迟；管理数据块的引用次数增加删除延迟。iDedup尝试解决这些问题，仅仅增加了5%的CPU开销和2-4%的操作延迟，重删率达到理想情况的60- 阅读全文

摘要： 大部分重复数据删除研究集中在备份的指纹索引上，大家都认为这是最关键的问题。的确，不解决磁盘瓶颈问题，备份窗口过大将导致重删不实用。重删系统的恢复性能一直处于被忽略的状态，原因是相对备份，恢复是小概率时间，而且体系结构最重要的Amdahl定律讲的就是重视大概率事件。但是我们也要明白一点，备份就是为了恢复的，如果备份的工作做得很充足，到了关键时刻不能快速恢复，一切都是白费力气了。或者说，备份就是一个不断投入的过程，而一次恢复就是赎回成本的过程，我们总是在研究如何减少备份的投入，而忽视了如何赎回更多的成本：恢复的越快，赎回的成本就越高！备份最关键的部分是指纹索引，恢复最关键的部分是数据块存储。重删的 阅读全文

摘要： 内存拷贝经常需要使用memcpy和strcpy：/*both defined in string.h*/void * memcpy ( void * destination, const void * source, size_t num );char * strcpy ( char * destination, const char * source );;二者主要的区别是strcpy将内存看作字符串，遇到0('')就结束。二者在使用时都存在一个不易发觉的陷阱。看下面这两行代码：memcpy(buf+off, buf, len);memcpy(buf, buf+off, le 阅读全文

摘要： MapReduce是由google首先提出来的编程模型（介绍点击这里），专为数据密集型任务而设计。不论是google还是hadoop，都是将MapReduce应用在大规模集群下的。那么它是否适共享内存环境呢？斯坦福的Phoenix项目做出了回答。相关的论文发表在HPCA’07（最佳论文）和MapReduce’11上。Phoenix适合于共享内存的多处理器计算机（SMP和ccNUMA），以及多核计算机。07年释出第一个版本Phoenix；后经过了大量修改，Phoenix 2在可扩展性和移植性方面得到加强，支持Linux；Phoenix++是Phoenix的C++实现。目前Phoenix只支持x8 阅读全文

摘要： 这篇文章有几个特点：第一是难懂，所谓Pastiche就是东拼西凑，涉及到很多别的技术，作者又没有一一详细解释，因此理解这篇文章俺是费了不少劲的；第二是“新颖”，其实这是篇古董文章，02年发表在OSDI，作者既没有完整实现一个系统，也没有很系统的实验，却能发表在A类会议上，我只能说作者的观察很独特。Pastiche描绘的是一个廉价的、p2p网络备份系统，它利用用户的剩余磁盘空间互相提供数据保护。遗憾的是，直到10年后的今天我也没有看到一个成熟的实现（也许是我孤陋寡闻）。但是因为很喜欢这个idea，还是决定发一篇博文。关于整个系统如何运转涉及太多细节，不一一描述，只在此记录下几个关键点。1. 观察 阅读全文

摘要： 使用普通的open、lseek操作文件，当文件达到2GB的时候写数据就会失败。这也是显然的，lseek的原型是long lseek(int handle, long offset, int fromwhere);long在32位操作系统上只有4个字节，只能寻址正负2GB的数据。lseek64是用于读写大文件的API，原型是off64_t lseek64(int fd, off64_t offset, int whence);通过这个函数就可以寻址超过2GB的大文件了。最后不要忘了为open加上O_LARGEFILE标记，或者直接使用open64函数打开文件，这二者是等价的。参考资料[1] ls 阅读全文