<h2>简介</h2>    <p>Btrfs是下一代的copy-on-write文件系统，它支持很多高级特性，使其更加适合Docker。Btrfs合并在内核主线中，并且它的on-disk-format也逐渐稳定了。不过，它的很多特性还仍然处于开发中。</p>    <p>Docker的btrfs存储驱动利用了很多Btrfs特性来管理镜像和容器。这些特性中最重要的就是thin provisioning（超配）、copy-on-write和快照。</p>    <h2>Btrfs特性</h2>    <p>Btrfs一直被认为是Linux文件系统的未来。在Linux内核主线的全力支持下，稳定的on-disk-format，关注于稳定性的积极开发，使得Btrfs逐渐成为现实。</p>    <p>只要Docker还在Linux平台上运行，人们就会认为btrfs存储驱动会替代devicemapper存储驱动，成为潜在的长期的存储驱动。然而，在写耗时上，devicemapper被认为更安全，更稳定，更适合商品化。只有当你很了解Btrfs，并且有丰富的经验时，才可以考虑btrfs驱动商品化。</p>    <h2>镜像分层和共享Btrfs</h2>    <p>Docker利用Btrfs的子卷（subvolumes）和快照来管理镜像和容器层的on-disk组件。Btrfs子卷像是一个普通的Unix文件系统。同样，当挂靠到Unix文件系统时，它们可以有自己的内部目录结构。</p>    <p>子卷是原生的copy-on-write，还有着按需分配的足够的空间，这些空间来自于下层的存储池。它们也可以拥有子卷，也可以使用快照。下图显示了4个子卷，子卷2和子卷3挂靠在其他子卷之上，子卷4显示了自己内部的目录树。</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/06e3d3941c0d5184de79486b9e1c211a.jpg"></p>    <p>快照是某个时间点整个子卷的读写拷贝。它们直接位于其父-子卷之下。示例如下：</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/34983a2f1f1826420ae82f01e699bfa4.jpg"></p>    <p>Btrfs从下层的存储池中，按需地为子卷和快照分配空间。分配的单位是chunk（大块），大块的大小通常是1GB左右。</p>    <p>快照是Btrfs文件系统的“一等公民”，它操作时就像普通的子卷。由于Btrfs原生的copy-on-write设计，创建快照可以直接在Btrfs文件系统中构建。这意味着Btrfs快照空间利用率很高，很少或是没有性能消耗。下图显示了子卷和它快照如何分享相同数据的。</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/270364b240ecc087d5ef59234bbc17f4.jpg"></p>    <p>Docker的btrfs存储驱动把每个镜像层和容器都保存在它们自己的Btrfs子卷或者快照中。底部镜像保存为子卷，而他的子镜像层和容器都保存为快照。下图展示了该特性。</p>    <p style="text-align:center"><img src="https://simg.open-open.com/show/0e5c49069d4346b34fb7732aca3bb357.jpg"></p>    <p>Docker是如下使用btrfs驱动的：</p>    <p>1) 镜像的底层保存为Btrfs子卷，位于/var/lib/docker/btrfs/subvolumes目录下。</p>    <p>2) 随后的镜像层都保存为父层（子卷或快照）的Btrfs快照。</p>    <h2>镜像和容器on-disk构建</h2>    <p>镜像层和容器可在Docker host的文件系统下直接看到，目录为/var/lib/docker/btrfs/subvolumes/。即使容器停止了，但其目录依然存在。这是因为btrfs存储驱动映射了一个默认的，最高等级的子卷在/var/lib/docker/btrfs/subvolumes/下。所有其他的子卷都作为Btrfs文件系统给的对象而存在于该卷之下，而不是各自独立的映射。</p>    <p>因为Btrfs工作在文件系统级别，而不是块级别，可以通过普通的Unix命令直接浏览镜像和容器层的内容。可以通过ls -l等简单命令来显示镜像层的内容，以下为一个删节的输出：</p>    <pre>  <code class="language-groovy">$ ls -l /var/lib/docker/btrfs/subvolumes/0a17decee4139b0de68478f149cc16346f5e711c5ae3bb969895f22dd6723751/    total 0  drwxr-xr-x 1 root root 1372 Oct  9 08:39 bin  drwxr-xr-x 1 root root    0 Apr 10  2014 boot  drwxr-xr-x 1 root root  882 Oct  9 08:38 dev  drwxr-xr-x 1 root root 2040 Oct 12 17:27 etc  drwxr-xr-x 1 root root    0 Apr 10  2014 home  ...output truncated...</code></pre>    <h2>容器使用Btrfs读写</h2>    <p>容器是镜像的一个高效利用空间的快照，快照中的元数据指向存储池中的实际数据块，这个和子卷是一致的。因此，从快照中读和从子卷中读本质上是一样的。所以，Btrfs驱动没有额外的性能损耗。</p>    <p>写一个新的文件，是一个按需分配的操作，会分配新的数据块给容器快照。文件也会写到这块新的空间。按需分配操作和所有Btrfs写操作一样，和写新数据到子卷也是一样的。因此，向容器快照写文件操作和原生的Btrfs操作速度一致。</p>    <p>在容器中更新一个已经存在的文件会引起copy-on-write操作（实际上是redirect-on-write），驱动不操作源数据，新分配一块空间给快照。更新的数据写在这块新空间上，然后，驱动更新快照中的文件系统系统元数据，指向这块新数据。该行为只有极小的损耗。</p>    <p>使用Btfs，写和更新大量小文件时，会使得性能缓慢。</p>    <h2>在Docker中配置Btrfs</h2>    <p>btrfs存储驱动只有在/var/lib/docker被映射在一个Btrfs文件系统时才能被使用。以下步骤展示如何在Ubuntu 14.04 LTS上配置Brtfs。</p>    <h3>准备知识</h3>    <p>如果你已经在你的Docker host上使用了Docker daemon，还有些镜像想保存，那么在尝试Btrfs之前，你需要先把镜像推送到Docker Hub或者你的私有仓库。</p>    <p>停止Docker daemon。然后，确保你在/dev/xvdb下有空闲的块设备。</p>    <p>另外，还需要确定你的OS上是否已经加载了Btrfs模块。输入以下命令确认：</p>    <pre>  <code class="language-groovy">$ cat /proc/filesystems | grep btrfs            btrfs</code></pre>    <h3>在Ubuntu 14.04 LTS上配置Btrfs</h3>    <p>如果你的OS满足前面的要求，那么如下操作：</p>    <p>1) 安装btrfs-tools包。</p>    <pre>  <code class="language-groovy">$ sudo apt-get install btrfs-tools     Reading package lists... Done   Building dependency tree   <output truncated></code></pre>    <p>2) 创建Btrfs存储池。</p>    <p>通过mkfs.btrfs命令创建Btrfs存储池。给mkfs.btrfs命令传递多个设备则可以创建一个使用多个设备的存储池。这里我们演示一下创建单个设备（/dev/xvdb）的池。</p>    <pre>  <code class="language-groovy">$ sudo mkfs.btrfs -f /dev/xvdb     WARNING! - Btrfs v3.12 IS EXPERIMENTAL   WARNING! - see http://btrfs.wiki.kernel.org before using     Turning ON incompat feature 'extref': increased hardlink limit per file to 65536   fs created label (null) on /dev/xvdb       nodesize 16384 leafsize 16384 sectorsize 4096 size 4.00GiB   Btrfs v3.12</code></pre>    <p>记得把/dev/xvdb替换为你系统中的实际设备名称。</p>    <p><em>再次提醒</em> ：如前面提到的，Btrfs暂时来看，不建议作为产品来使用，除非你有着丰富的经验。</p>    <p>3) 在本地存储创建 /var/lib/docker。</p>    <pre>  <code class="language-groovy">$ sudo mkdir /var/lib/docker</code></pre>    <p>4) 使Btrfs文件系统在系统重启时会自映射。</p>    <p>a. 获取Btrfs文件系统的UUID。</p>    <pre>  <code class="language-groovy">$ sudo blkid /dev/xvdb    /dev/xvdb: UUID="a0ed851e-158b-4120-8416-c9b072c8cf47"  UUID_SUB="c3927a64-4454-4eef-95c2-a7d44ac0cf27" TYPE="btrfs"</code></pre>    <p>b. 在/etc/fstab中增加一行条目，使得系统启动时可以自动映射/var/lib/docker。下面两行每一行都可以生效，当然，在你实际操作中，记得替换为自己的UUID。</p>    <pre>  <code class="language-groovy">/dev/xvdb /var/lib/docker btrfs defaults 0 0   UUID="a0ed851e-158b-4120-8416-c9b072c8cf47" /var/lib/docker btrfs defaults 0 0</code></pre>    <p>5.映射新的文件系统，并确认操作是否成功。</p>    <pre>  <code class="language-groovy">$ sudo mount -a    $ mount    /dev/xvda1 on / type ext4 (rw,discard)  <output truncated>  /dev/xvdb on /var/lib/docker type btrfs (rw)</code></pre>    <p>6.然后，重启docker服务。</p>    <pre>  <code class="language-groovy">$ sudo service docker start    docker start/running, process 2315</code></pre>    <p>当然，由于你使用的Linux发行版可能不同，启动Docker Daemon的方法可能也不同。</p>    <p>这里，在启动Docker Daemon之前，你可以强行指定Daemon的存储驱动为btrfs存储驱动。可以在daemon启动命令行时传递--storage-driver=btrfs 参数，也可以在Docker配置文件中修改DOCKER_OPTS参数。</p>    <p>7.通过docker info命令验证。</p>    <pre>  <code class="language-groovy">$ sudo docker info    Containers: 0  Images: 0  Storage Driver: btrfs  [...]</code></pre>    <h2>btrfs和Docker性能</h2>    <p>在btrfs存储驱动下，有以下一些原因可以影响Docker的性能。</p>    <ul>     <li>Page caching，页缓存。Btrfs不支持页缓存共享，也就是说n个容器访问同一个文件会请求n份缓存拷贝。因此，btrfs驱动可能不是Paas或者高密集容器的最优选项。</li>     <li>Small writes，小的写请求。容器执行大量写的写请求（包括Docker host启动和停止很多容器）会导致Btrfs大块只使用了很小一部分，最终会导致Docker host空间不足，停止服务。这是当前使用Btrfs的一个最重大的缺点。<br> 如果使用btrfs存储驱动，需要密切监视Btrfs文件系统的可用空间，可用使用btrfs filesys shwo来观察。不用相信常规的Unix命令（如df）的输出。</li>     <li>Sequential writes，顺序写。Btrfs通过日志技术写数据到磁盘，这回导致顺序写的性能减半。</li>     <li>Fragmentation。存储残片是像Btrfs这种copy-on-write文件系统的天然副产品，很多小的随机写会产生这个问题。它可以表现为使用SSD介质的Docker主机上的CPU峰值和使用旋转介质的Docker主机上的抖动（It can manifest as CPU spikes on Docker hosts using SSD media and head thrashing on Docker hosts using spinning media.不是很理解这句）。这两个都会导致性能很差。<br> Btrfs的最近版本允许你制定autodefrag作为一个映射点。这种模式下，会探测到随机写并进行碎片整理。在确定使用Btrfs之前，你应该在你的Docker host上进行测试。一些测试显示，在执行大量的samll writes操作时（包括启停很多容器），这个选项会有一些负面的性能问题。</li>     <li>Solid State Devices（SSD）。Btrfs有原生的SSD优化，可以通过映射时加上-o ssd映射选项来使能它。这些优化包括在SSD介质上避免seek之类的操作来增强SSD写性能，因为这类操作在SSD上没有任何作用。<br> Btrfs也支持TRIM/Discard元操作。然而，映射时加上 -o discard 的选项会导致性能问题。因此，还是建议在使用之前做些测试。</li>     <li>Use Data Volumes。数据卷提供最优和最可预测的性能。因为它们可以绕过存储驱动，不会引起任何超配和copy-on-write可能会导致的潜在的负载。</li>     <li> <p>Balance BTRFS。开启一个cron任务来均衡你的BTRFS设备，比如均衡地传输子卷的块给raid设备，回收未使用的块。如果不这样做，docker删除的快照和子卷会遗留分配了的块，这些块装满了BTRFS根卷的。一旦你没有执行再均衡操作，在不添加额外的存储设备情况下，会导致潜在的不可恢复的状态。如果你不愿意使用crond来自动执行，另一个方法是在非峰值时手动执行再均衡命令，因此为这种操作时磁盘I/O密集型操作。此命令按要求所有的大块使用了1%或者更少：</p> <pre>  <code class="language-groovy">$ sudo btrfs filesystem balance start -dusage=1 /var/lib/docker  Dumping filters: flags 0x1, state 0x0, force is off DATA (flags 0x2): balancing, usage=1 Done, had to relocate 673 out of 842 chunks</code></pre> <h2>小结</h2> <p>Btrfs存储驱动的主要特性就是超配，copy-on-write和快照。与AuFS或者devmapper不同，要在Docker上使用Btrfs，要求整个/var/lib/docker所处的文件系统就是Btrfs。此外，btrfs存储驱动由于现在还在重度开发中，现在最多的就是各种性能问题。所以，官方也不建议直接在Docker生产环境中使用，除非，你在Btrfs上有着丰富的经验。</p> </li>    </ul>    <p> </p>    <p>来自：http://www.cnblogs.com/styshoo/p/6482347.html</p>    <p> </p>