Btrfs是下一代的copy-on-write文件系统，它支持很多高级特性，使其更加适合Docker。Btrfs合并在内核主线中，并且它的on-disk-format也逐渐稳定了。不过，它的很多特性还仍然处于开发中。
Docker的btrfs存储驱动利用了很多Btrfs特性来管理镜像和容器。这些特性中最重要的就是thin provisioning（超配）、copy-on-write和快照。
Btrfs一直被认为是Linux文件系统的未来。在Linux内核主线的全力支持下，稳定的on-disk-format，关注于稳定性的积极开发，使得Btrfs逐渐成为现实。
只要Docker还在Linux平台上运行，人们就会认为btrfs存储驱动会替代devicemapper存储驱动，成为潜在的长期的存储驱动。然而，在写耗时上，devicemapper被认为更安全，更稳定，更适合商品化。只有当你很了解Btrfs，并且有丰富的经验时，才可以考虑btrfs驱动商品化。
Docker利用Btrfs的子卷（subvolumes）和快照来管理镜像和容器层的on-disk组件。Btrfs子卷像是一个普通的Unix文件系统。同样，当挂靠到Unix文件系统时，它们可以有自己的内部目录结构。
子卷是原生的copy-on-write，还有着按需分配的足够的空间，这些空间来自于下层的存储池。它们也可以拥有子卷，也可以使用快照。下图显示了4个子卷，子卷2和子卷3挂靠在其他子卷之上，子卷4显示了自己内部的目录树。
快照是某个时间点整个子卷的读写拷贝。它们直接位于其父-子卷之下。示例如下：
Btrfs从下层的存储池中，按需地为子卷和快照分配空间。分配的单位是chunk（大块），大块的大小通常是1GB左右。
快照是Btrfs文件系统的“一等公民”，它操作时就像普通的子卷。由于Btrfs原生的copy-on-write设计，创建快照可以直接在Btrfs文件系统中构建。这意味着Btrfs快照空间利用率很高，很少或是没有性能消耗。下图显示了子卷和它快照如何分享相同数据的。
Docker的btrfs存储驱动把每个镜像层和容器都保存在它们自己的Btrfs子卷或者快照中。底部镜像保存为子卷，而他的子镜像层和容器都保存为快照。下图展示了该特性。
Docker是如下使用btrfs驱动的：
1) 镜像的底层保存为Btrfs子卷，位于/var/lib/docker/btrfs/subvolumes目录下。
2) 随后的镜像层都保存为父层（子卷或快照）的Btrfs快照。 镜像和容器on-disk构建
镜像层和容器可在Docker host的文件系统下直接看到，目录为/var/lib/docker/btrfs/subvolumes/。即使容器停止了，但其目录依然存在。这是因为btrfs存储驱动映射了一个默认的，最高等级的子卷在/var/lib/docker/btrfs/subvolumes/下。所有其他的子卷都作为Btrfs文件系统给的对象而存在于该卷之下，而不是各自独立的映射。
因为Btrfs工作在文件系统级别，而不是块级别，可以通过普通的Unix命令直接浏览镜像和容器层的内容。可以通过ls -l等简单命令来显示镜像层的内容，以下为一个删节的输出：
容器是镜像的一个高效利用空间的快照，快照中的元数据指向存储池中的实际数据块，这个和子卷是一致的。因此，从快照中读和从子卷中读本质上是一样的。所以，Btrfs驱动没有额外的性能损耗。
写一个新的文件，是一个按需分配的操作，会分配新的数据块给容器快照。文件也会写到这块新的空间。按需分配操作和所有Btrfs写操作一样，和写新数据到子卷也是一样的。因此，向容器快照写文件操作和原生的Btrfs操作速度一致。
在容器中更新一个已经存在的文件会引起copy-on-write操作（实际上是redirect-on-write），驱动不操作源数据，新分配一块空间给快照。更新的数据写在这块新空间上，然后，驱动更新快照中的文件系统系统元数据，指向这块新数据。该行为只有极小的损耗。
使用Btfs，写和更新大量小文件时，会使得性能缓慢。