林健的BLOG

　　受 @Sisyphusliu 师兄的启发，我最近决定试用 Amazon S3 来做个人数据同步与备份。初步计算发现这很可能比之前使用 VPS 或 Web 主机的方案要节约成本。我对三款面向 Amazon S3 的开源文件同步工具进行了对比，将其中部分细节说明如下，供有相同需求的朋友参考。
　　这三款工具分别是 jets3t、s3cmd 和 s3sync.rb。其主要特性和附加功能这里不再赘述，它们的官方主页都有详细说明。软件的稳定性还有待长时间使用的考验，但从网上没有发现用户反映太大的问题。我在这里强调它们存储文件元信息的差别，以及由此可能引发的问题。

　　由于 S3 基于 Key-Object 存储方式，与树型文件系统不同，因此如何将树型结构组织的文件及其元信息存储在 S3 中就是一个问题。这三款工具都将文件的全路径作为 Key，并把文件的元信息保存在 Object 的自定义属性中。
　　这样有什么后果呢？首先看目录。稍稍想想就会发现，像“a/b/c”这样的 Key 无法直接判定“c”是一个目录还是一个文件。s3cmd 的处理最简单，它的任何一个 Object 都是文件，不把目录作为 Object 保存。这样消除了歧义，但导致了目录的元信息无从保留，同时也无法保存空目录。而 jets3t 和 s3sync.rb 会保存目录的 Object，并通过元信息中的 Content-Type 来区别文件与目录。这样就保留了目录元信息，也允许空目录存在，但这影响了工具之间的互操作性。下载另一个工具上传的文件时，工具彼此不认识对方的目录 Object，就会将它们保存成普通文件，从而造成同名的目录无法创建。
　　再来看看文件的元信息。s3cmd 保存的 s3cmd-attrs 属性是一个包含了 uid、gid、uname、gname、mtime、atime、ctime 等信息的字符串，因此它保留了最完整的文件元信息。jets3t 只保存文件修改时间，无从得知属主与权限，不适合保存可执行程序的目录；s3sync.rb 只保存属主与权限，而且是数字 id 而非名字，在新系统中恢复数据时可能出现映射错误。
　　我个人倾向于选择 s3cmd。其一，文件修改时间和权限对于个人程序、文档来说是比较重要的信息。当然这不是技术问题，修改 jets3t 和 s3sync.rb 肯定也能做到。其二，不使用自定义的目录 Object 就允许一定程度的互操作，例如使用 jets3t 和 s3sync.rb 可以直接下载 s3cmd 上传的文件与目录结构（元信息丢失）。而 s3cmd 设计造成的目录元信息缺失、空目录消失等问题，对一般应用和文档来说不太重要、相对容易恢复。当然也可以使用额外的机制来记录目录元信息，但考虑 KISS 原则，s3cmd 目前的设计还是有道理的。要想同时解决元信息与目录问题，容易想到的办法是将目录打包或压缩再上传，这比较适于长周期的文件归档备份场景，但对于细粒度、短周期的日常数据同步场景并不适合。
　　至于云存储的信任问题，在现阶段我也只能选择折衷。一方面不要将鸡蛋放在一个篮子里，重要数据还是需要异地备份的。另一方面可以使用这些同步工具自带的安全机制，或自己稍加封装实现数据加密。
　　最后提醒大家，务必看看 Joel 的备份观。

　　Btrfs 凭借着其优良的可伸缩性和诸多有用的特性，有望成为 Linux 下一代文件系统。目前它已被纳入主流内核支持，接受用户的实验性（Experimental）使用。
　　今年 2 月 hutuworm 给出了一篇《Ext4 ReiserFS Btrfs 等七种文件系统性能比拼》，他是在 2.6.29-rc3 内核上使用 IOZone 3.318 做的测试。Btrfs 官方 Wiki 也给出了一些第三方测试数据，基于的是 4、5 月份的版本。官方 Wiki 同时指出他们在不断解决这些测试中所发现的问题和瓶颈。这几天我也对 Btrfs 进行了一些测试，并针对某些新特性进行了研究。我的测试基于 2.6.32 内核，使用的工具是 IOZone 3.327，对比对象为 ext3 和 ext4，机器配置为 2 * 4Cores Xeon 2.0G / 8G Memory。从测试结果看，性能方面，Btrfs 在 CPU Cache 区和 Buffer Cahce 区较好，在 Disk I/O 区不如 ext3/ext4（所谓三个区的划分参考 IOZone 文档）；可靠性方面，Btrfs 仍有待加强。下面简述我的几条观察（详细数据省略）。

./iozone -Rab output.xls -g 16G

./iozone -Rab output.xls -s 16G -r 2M

tar cf *.tar *; tar jcf *.tar.bz2 *

　　性能方面：
　　1．CPU Cache 区和 Buffer Cahce 区的 read 吞吐率，Btrfs、ext3、ext4 相差不大。
　　2．CPU Cache 区和 Buffer Cahce 区的 write 吞吐率，明显地 Btrfs 优于 ext4 优于 ext3（tar 测试检验了这个结果）。
　　3．Disk I/O 区的 read 吞吐率 ext3 占优，write 吞吐率 ext4 占优，而 Btrfs 两方面均劣于 ext3、ext4（与 hutuworm 的结论类似）。
　　4．三个文件系统对于小于 CPU Cache 区的小文件，都有“文件或记录过小时读写性能变差”的问题。其负面影响程度 BtrFS 大于 ext4 大于 ext3。
　　而可靠性方面，常规的读写校验并没有出现问题，但在测试 Copy on write（COW）特性时，先后遇到两个错误：
　　1．最初使用 2.6.31-15 内核测试，出现了克隆文件与原始文件计算 MD5 有可能不一致的问题。开发人员回复说这个 bug 已经在 2.6.32-rc 以后的内核中修复。升级内核后此问题得以解决。
　　2．目前使用 2.6.32 内核测试，发现同时读写原始文件和克隆文件，有可能致使 syslogd 出错、文件系统没有响应。现在我还没有得到可靠的答复，但相关回复者基本怀疑是竞态问题。
　　有关 Btrfs 其它的高级特性我还没有详细测试。正在使用或打算使用 Btrfs 的朋友，也欢迎与我交流。