"生活中曾各大门户、微博、博客逛来逛去，合上电脑，闭上眼睡觉什么都没留下，唯有总结才能有收获。"，曾经在某个博客那里看到的一句话，挺有道理的~这也是写这篇文章的动力，为了了解Btrfs，看了很多资料和收藏了很多好的博主见解链接，本来只想默默地放在浏览器里，等哪天忘了再去翻出来看看，但正因为那句话，最终还是决定自己整理一个文档出来，做做搬运工，随便加上自己的一些见解~那么，下面就开始说说我从Arch中认识的Btrfs~

折腾了一个星期的Archlinux，学到的东西挺多的，特别是Arch其包管理的工具pacman，真的很赞，还有Arch的wiki和bbs，其上面的文档教程很完善详细，可以说得上样样俱全~额，等等，这好像和Btrfs没半毛钱关系啊。不不不，少侠，别急，下面就讲讲Btrfs。

唠叨几句：折腾Arch为什么要讲Btrfs呢？这得从头说起呀，很久很久以前，在一片幽邃的森林里，住着一位森之守护神——…Stop！这是什么和什么？23333，好，请原谅我的中二，来个正式的：

第一次安装arch的时候，用的文件系统是大众的ext4。有一天宿主机(安装的Arch是一台kvm虚拟机，以下简称AK)异常宕机了，ssh进不去了，只好去机房手动强制重启，结果导致宿主机上的AK在开机的时候一直在做Log Replay的动作，等了老半天还是一直stuck，鉴于是实验的虚拟机，干脆重新安装AK。重装AK的时候，在选择文件系统的时候，我特意去看了wiki上面罗列的文件系统格式，列如：linux下面的ext家族以及XFS、ZFS、JFS、Btrfs等，Mac OS上的HFS，Windows上的NTFS。各种文件系统的介绍@Arch wiki：https://wiki.archlinux.org/index.php/File_systems

其中我选择了Btrfs，别问我为什么，还记得初中语文老师说过：选择题遇到不会的，三长两短，选最长的！是的，Btrfs的介绍在wiki上面是最详细的。这是其中一个原因。另外，在linux吧以及度娘上收集到的Arch安装资料中多少都有提到过btrfs，而且，openSUSE 13.2和Fedora16测试版中都是默认的文件系统，只是鉴于当初的表现不稳定取消了其默认文件系统而已。之后，我特地安装了openSUSE-42.1和Fedora-24，在选择文件系统的时候，依旧看到Btrfs(PS：两者默认文件系统是XFS，RedHat7默认也是XFS)。那么，当初为什么会取消Btrfs作为默认文件系统呢，归根结底，主要原因是当时的内核支持不够完善。而现在，内主线版本发展到了4.7，已经可以很好的支持Btrfs了。在Arch上，目前使用的内核是4.6.3，嗯，“就这样被你征服，切断了所有退路”，好的，就这样，我选了Btrfs，下面正式介绍Btrfs。

Btrfs的简介摘录地址：https://wiki.archlinux.org/index.php/Btrfs

Btrfs（B-tree 文件系统，通常念成 Butter FS，Better FS或B-tree FS），一种支持写时复制（COW）的文件系统，运行在Linux操作系统上，采用GPL授权。Oracle于2007年对外宣布这项计划，并发布源代码，2014年8月发布稳定版。目标是取代Linux当时主流的ext3 文件系统，摆脱ext3的一些限制，特別是单文件大小，文件系统总大小和文件校验，并加入ext3 不支持的一些功能，比如可写快照（writable snapshots）、快照的快照（snapshots of snapshots）、内建磁盘阵列（RAID），以及子卷（subvolumes）。Btrfs也宣称专注于「容错、修复及易于管理」。

Btrfs是一种新型的写时复制(COW)Linux文件系统，已经编入内核主线。Btrfs设计实现高级功能的同时，着重于容错、修复以及易于管理。它由 Oracle, Red Hat, Fujitsu, Intel, SUSE, STRATO 等企业和开发者共同开发, Btrfs以GNU GPL协议授权,同时欢迎任何人的贡献。

简单的说，Btrfs是一种新型的文件系统，专注于高容错、易修复及易管理，功能多多，得到了众多企业和开发者的支持，其目标计划是替代linux目前的ext3/4，成为下一代linux标准的文件系统。

Btrfs核心特性：

1,类似lvm的多物理卷支持，btrfs可以跨越多个物理磁盘设备，可以通过动态的增加/减少磁盘设备来达到扩容/收缩的目的，其操作过程极其简便，lvm在这一点上可以做冷板凳了。而且，btrfs内建raid，技术上支持raid0/1/5/10等特性。

2,文件系统的COW(Copy On Write)写时复制，所谓COW，即修改A文件时，先把A当前快数据读出来，写到B块，并在B块上进行修改，当B块写入完成，只需将原来指向旧块的指针指向新块。假设该过程操作失败或中途断电也不会影响superblock的原来指向，数据依然是操作前的状态，从而保证了事务的完整性和文件系统的一致性。简单点说，COW的文件系统好处是对文件系统元数据的保护（元数据包括文件名、文件大小、属性、路径结构等等），而且没有日志文件系统中Log Replay的机制。

3,灵活的字卷(subvolume)：在一个btrfs设备中，subvolume的存在充分的体现了B-tree的文件系统组织方式。即把多个/单个磁盘/分区设备配置为一个btrfs文件系统设备，称之为subvolume，但这个subvolume是整个设备的总结点，是森林的根、总树根，（标识一个subvolume有两个数据：名称和ID），而且建立文件系统后，会自动生成总树根，没有名称，ID为0。之后可在其上面建立文件、文件夹和子树，文件夹和子树中又能包含别的文件、文件夹和子树。子树和文件夹的区别在于，子树能够用mount命令直挂载在到总树根部，也可以对其快照而文件夹不行。subvolume可以充分使用共享底层的设备空间，更好的扩展性与快照回滚能力，简化磁盘空间管理、充分利用了磁盘带宽。

可以这样说，一个btrfs设备相当于一个深林的总根，而子卷相当于其中的一个子树，子树上面不断延生的枝干则相当于我们在子卷中创建子卷的子卷、子卷的文件、子卷的文件夹。当我们单独挂载子卷时，此时，站在总树根的角度来看，子卷不再是子卷，而是作为另一森林的总根，在其上面创建的子卷又将会成为新的子树。

4,强大的快照(snapshot)：btrfs能对任何subvolume进行快照，能做到文件级别的快照，可以在快照中再做快照，能够把快照也当成一个subvolume，而且快照能够设置可读/可写。

5,透明压缩：在用户写入数据时系统会自动进行压缩，而用户调用数据的过程是一个解压缩的过程，但是这个过程，对用户来说是透明的，是自动进行的。官网显示，目前支持的压缩算法是lzo和zlib，在以后会支持lz4、snappy、lzma。压缩算法具体介绍@官网：https://btrfs.wiki.kernel.org/index.php/Compression

6,使用checksum来保证数据及元数据的可靠，例如：btrfs在读取数据的同时会读取其相应的checksum，如果最终从磁盘读取出来的数据和checksum不相同，btrfs 会首先尝试读取数据的镜像备份，如果数据没有镜像备份，btrfs 将返回错误。写入磁盘数据之前，btrfs会计算数据的checksum。然后将checksum和数据同时写入磁盘。

7,btrfs设计时考虑到了ssd的优化，在挂载ssd设备的时候可指定属于ssd的挂载参数。

目前局限性:

1,不同subvolume只可以使用相同的压缩算法

2,不支持交换文件

3,不支持UEFI启动

4,没有内建的数据加密方式

以上就是Btrfs的介绍和核心特性，大部分内容都可以从Arch的wiki和Btrfs的wiki找到，其中有的内容是摘录其它博主的，也有自己查阅官网手册理解总结的。站在个人角度上来看，我是觉得Btrfs真的是易管理、灵活。而对于高容错和易修复，由于未亲自在实际业务中实际运用过（唉，T-T上头也不可能允许这样做），不能断言。但是，在虚拟机做的实验可验证这两点，操作过程会在下一篇《Btrfs实践》文章中演示。其实，据网上一些资料显示，著名的社交网站Facebook在逐渐向Btrfs迁移，在Btrfs官网也找到了一些蛛丝马迹——https://btrfs.wiki.kernel.org/index.php/Production_Users，还有今年二月份国外的一篇文章也提到了——http://www.virtualtothecore.com/en/2016-btrfs-really-next-filesystem/。

还有就是，我们可以在众多linux发行版的官方wiki看到有关Btrfs的介绍和用法。

例如：

最后，贴上与Btrfs相关的网址：