Btrfs 和 LVM-ext4 该如何选择？
LVM ext4 Btrfs
![](/data/attachment/album/202101/23/133137m2wfkiq8ykyvwyhv.jpg)


[Fedora 33](https://fedoramagazine.org/announcing-fedora-33/) 在其各类桌面版本中引入了新的默认文件系统 [Btrfs](https://btrfs.wiki.kernel.org/index.php/Main_Page)。多年以来，Fedora 一直在 <ruby> <a href="https://man7.org/linux/man-pages/man8/lvm.8.html">  逻辑卷管理 </a> <rt>  Logical Volume Manager </rt></ruby>（LVM） 卷之上使用 [ext4](https://ext4.wiki.kernel.org/index.php/Main_Page)，引入 Brtfs 对 Fedora 来说是一个很大的转变。更改默认文件系统需要 [令人信服的原因](https://fedoraproject.org/wiki/Changes/BtrfsByDefault)。虽然 Btrfs 是令人兴奋的下一代文件系统，但 LVM 上的 ext4 是成熟而稳定的。本指南旨在探索各自的高级特性，使得更容易在 Btrfs 和 LVM-ext4 之间进行选择。


### 先说结论


最简单的建议是坚持使用默认值。全新安装的 Fedora 33 环境默认为 Btrfs，升级之前的 Fedora 版本将继续使用最初安装的设置，通常是 LVM-ext4。对于现有的 Fedora 用户来说，获取 Btrfs 的最简单方式是全新安装。然而，全新安装比简单升级更具破坏性。除非有特殊需要，否则这种干扰可能是不必要的。Fedora 开发团队仔细考虑了这两个默认值，因此对任何一个选择都要有信心。


### 那么其他文件系统呢？


现在有很多 [Linux 系统的文件系统](https://man7.org/linux/man-pages/man5/filesystems.5.html)。在加上卷管理器、加密方法和存储机制的组合后，这一数字呈爆炸式增长。那么，为什么要关注 btrfs 和 LVM-ext4 呢？对于 Fedora 的用户来说，这两种设置可能是最常见的。在 Fedora 11 中，LVM 之上的 ext4 成为了默认磁盘布局，在此之前则使用的是 ext3。


既然 Btrfs 是 Fedora 33 的默认设置，那么绝大多数现有用户会考虑是应该原地踏步还是向前跳跃。面对全新安装的 Fedora 33 环境，有经验的 Linux 用户可能会想知道是使用这个新的文件系统，还是退回到他们熟悉的文件系统。因此，在众多可能的存储选项中，许多 Fedora 用户会想知道如何在 Btrfs 和 LVM-ext4 之间进行选择。


### 两者的共性


尽管两个文件系统之间存在核心差异，但 Btrfs 和 LVM-ext4 实际上有很多共同之处。两者都是成熟且经过充分测试的存储技术。从 Fedora Core 的早期开始，就一直在使用 LVM，而 ext4 在 [2009 年成为 Fedora 11 的默认设置](https://docs.fedoraproject.org/en-US/Fedora/11/html/Release_Notes/index.html#sect-Release_Notes-Fedora_11_Overview)。Btrfs 在 2009 年并入 Linux 主线内核，并且 [Facebook 广泛使用了该文件系统](https://facebookmicrosites.github.io/btrfs/docs/btrfs-facebook.html)。SUSE Linux Enterprise 12 [在 2014 年使其成为默认文件系统](https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/#fate-317221)。因此，它在生产环境中也有着长久的运行时间。


这两个系统都能很好地防止因意外停电而导致的文件系统损坏，尽管它们的实现方式不同。它们支持的配置包括使用单盘设置和跨越多个设备，并且这两种配置都能够创建近乎即时的快照。有各种工具可以帮助管理这两种系统，包括命令行和图形界面。这两种解决方案在家用台式机和高端服务器上都同样有效。


### LVM-ext4 的优势


![LVM 上 ext4 的结构](/data/attachment/album/202101/23/133153m0vsive3khrr55ek.jpg)


[ext4 文件系统](https://opensource.com/article/18/4/ext4-filesystem) 专注于高性能和可伸缩性，没有太多额外的花哨之处。它能有效地防止长时间后的碎片化，并当碎片化出现后提供了 [很好的工具](https://man7.org/linux/man-pages/man8/e4defrag.8.html)。ext4 之所以坚如磐石，是因为它构建在前代的 ext3 文件系统之上，带来了多年的系统内测试和错误修复。


LVM-ext4 环境中的大多数高级功能都来自 LVM 本身。LVM 位于文件系统的“下方”，这意味着它支持任何文件系统。<ruby> 逻辑卷 <rt>  Logical volume </rt></ruby>（LV）是通用的块设备，因此 [虚拟机可以直接使用它们](https://libvirt.org/storage.html#StorageBackendLogical)。这种灵活性使得每个逻辑卷都可以使用合适的文件系统，用合适的选项应对各种情况。这种分层方法还遵循了“小工具协同工作”的 Unix 哲学。


从硬件抽象出来的<ruby> <a href="https://www.redhat.com/sysadmin/create-volume-group">  卷组 </a> <rt>  volume group </rt></ruby>（VG）允许 LVM 创建灵活的逻辑卷。每个逻辑卷都提取自同一个存储池，但具有自己的设置。调整卷的大小比调整物理分区的大小容易得多，因为没有数据有序放置的限制。LVM <ruby> <a href="https://www.redhat.com/sysadmin/create-physical-volume">  物理卷 </a> <rt>  physical volume </rt></ruby>（PV）可以是任意数量的分区，甚至可以在系统运行时在设备之间移动。


LVM 支持只读和读写的 [快照](https://tldp.org/HOWTO/LVM-HOWTO/snapshotintro.html)，这使得从活动系统创建一致的备份变得很容易。每个快照都有一个定义的大小，更改源卷或快照卷将占用其中的空间。又或者，逻辑卷也可以是<ruby> <a href="https://man7.org/linux/man-pages/man7/lvmthin.7.html">  稀疏配置池 </a> <rt>  thinly provisioned pool </rt></ruby>的一部分。这允许快照自动使用池中的数据，而不是使用在创建卷时定义的固定大小的块。


#### 有多个磁盘驱动器的 LVM


当有多个设备时，LVM 才真正大放异彩。它原生支持大多数 [RAID 级别](https://rhea.dev/articles/2018-08/LVM-RAID-on-Fedora)，每个逻辑卷可以具有不同的 RAID 级别。LVM 将自动为 RAID 配置选择适当的物理设备，或者用户可以直接指定它。基本的 RAID 支持包括用于性能的数据条带化（[RAID0](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_0)）和用于冗余的镜像（[RAID1](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_1)）。逻辑卷也可以使用 [RAID5](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_5)、[RAID6](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_6) 和 [RAID10](https://en.wikipedia.org/wiki/Non-standard_RAID_levels#Linux_MD_RAID_10) 等高级设置。LVM RAID 支持已经成熟，因为 LVM 在底层使用的 [设备映射器（dm）](https://man7.org/linux/man-pages/man8/dmsetup.8.html) 和 [多设备（md）](https://man7.org/linux/man-pages/man4/md.4.html) 内核支持， 与 [mdadm](https://fedoramagazine.org/managing-raid-arrays-with-mdadm/) 使用的一样。


对于具有快速和慢速驱动器的系统，逻辑卷也可以是 [缓存卷](https://man7.org/linux/man-pages/man7/lvmcache.7.html)。经典示例是 SSD 和传统磁盘驱动器的组合。缓存卷使用较快的驱动器来存储更频繁访问的数据（或用作写缓存），而慢速的驱动器则用于处理大量数据。


LVM 中大量稳定的功能以及 ext4 的可靠性在既往的使用中早已被证明了。当然，功能越多就越复杂。在配置 LVM 时，要找到合适的功能选项是很有挑战性的。对于单驱动器的台式机系统，LVM 的功能（例如 RAID 和缓存卷）不适用。但是，逻辑卷比物理分区更灵活，快照也很有用。对于正常的桌面使用，LVM 的复杂性会成为典型的用户可能遇到的问题恢复的障碍。


### Btrfs 的优势


![Btrfs 结构](/data/attachment/album/202101/23/133153ytf8tgzi7izzdz8t.jpg)


从前几代文件系统中学到的经验指导了构建到 [Btrfs](https://btrfs.wiki.kernel.org/index.php/Main_Page) 的功能设计。与 ext4 不同，它可以直接跨越多个设备，因此它具有通常仅在卷管理器中才能找到的功能。它还具有 Linux 文件系统空间中独有的功能（[ZFS](https://en.wikipedia.org/wiki/ZFS) 具有相似的功能集，但[不要指望它在 Linux 内核中出现](https://itsfoss.com/linus-torvalds-zfs/)）。


#### Btrfs 的主要功能


也许最重要的功能是对所有数据进行<ruby> 校验和 <rt>  checksumming </rt></ruby>。校验和与<ruby> <a href="https://en.wikipedia.org/wiki/Copy-on-write">  写时复制 </a> <rt>  copy-on-write </rt></ruby>（COW）一起，提供了在意外断电后确保文件系统完整性的 [关键方法](https://btrfs.wiki.kernel.org/index.php/FAQ#Can_I_have_nodatacow_.28or_chattr_.2BC.29_but_still_have_checksumming.3F)。更独特的是，校验和可以检测数据本身中的错误。悄然的数据损坏（有时也称为 [bitrot](https://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows-inside-next-gen-filesystems/)）比大多数人意识到的更常见。如果没有主动验证，损坏最终可能会传播到所有可用的备份中。这使得用户没有有效的副本。通过透明地校验所有数据，Btrfs 能够立即检测到任何此类损坏。启用正确的 [dup 或 raid 选项](https://man7.org/linux/man-pages/man8/mkfs.btrfs.8.html#DUP_PROFILES_ON_A_SINGLE_DEVICE)，文件系统也可以透明地修复损坏。


写时复制也是 Btrfs 的基本功能，因为它在提供文件系统完整性和即时子卷快照方面至关重要。从公共子卷创建快照后，快照会自动共享底层数据。另外，事后的<ruby> <a href="https://btrfs.wiki.kernel.org/index.php/Deduplication">  重复数据删除 </a> <rt>  deduplication </rt></ruby> 使用相同的技术来消除相同的数据块。单个文件可以通过使用 `cp` 的 [reflink 选项](https://btrfs.wiki.kernel.org/index.php/UseCases#How_do_I_copy_a_large_file_and_utilize_COW_to_keep_it_from_actually_being_copied.3F) 来使用 COW 功能。reflink 副本对于复制大型文件（例如虚拟机镜像）特别有用，这些文件往往随着时间的推移具有大部分相同的数据。


Btrfs 支持跨越多个设备，而无需卷管理器。多设备支持可提供数据镜像功能以实现冗余和条带化以提高性能。此外，还实验性地支持更高级的 RAID 级别，例如 [RAID 5](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_5) 和 [RAID 6](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_6)。与标准 RAID 设置不同，Btrfs 的 RAID1 实际上允许奇数个设备。例如，它可以使用 3 个设备，即使它们的大小不同。


所有 RAID 和 dup 选项都是在文件系统级别指定的。因此，各个子卷不能使用不同的选项。请注意，使用多设备的 RAID1 选项意味着即使一个设备发生故障，卷中的所有数据都是可用的，并且校验功能可以保持数据本身的完整性。这超出了当前典型的 RAID 设置所能提供的范围。


#### 附加功能


Btrfs 还支持快速简便的远程备份。子卷快照可以 [发送到远程系统](https://fedoramagazine.org/btrfs-snapshots-backup-incremental/) 进行存储。通过利用文件系统中固有的 COW 元数据，这些传输通过仅发送先前发送的快照中的增量更改而非常有效。诸如 [snapper](http://snapper.io/) 之类的用户应用程序使管理这些快照变得容易。


另外，Btrfs 卷可以具有 [透明压缩](https://btrfs.wiki.kernel.org/index.php/Compression) 功能，并且 [chattr +c](https://www.man7.org/linux/man-pages/man1/chattr.1.html) 可以标记进行压缩的单个文件或目录。压缩不仅可以减少数据消耗的空间，还可以通过减少写入操作量来帮助延长 SSD 的寿命。压缩当然会带来额外的 CPU 开销，但是有很多选项就可以权衡取舍。


Btrfs 集成了文件系统和卷管理器功能，这意味着总体维护比 LVM-ext4 更简单。当然，这种集成的灵活性较低，但是对于大多数台式机甚至服务器而言，设置已足够。


### LVM 上使用 Btrfs


Btrfs 可以 [就地转换 ext3/ext4 文件系统](https://btrfs.wiki.kernel.org/index.php/Conversion_from_Ext3)。就地转换意味着无需将数据复制出来然后再复制回去。数据块本身甚至都不需要修改。因此，对于现有的 LVM-ext4 系统，一种选择是将 LVM 保留在原处，然后简单地将 ext4 转换为 Btrfs。虽然可行且受支持，但有一些原因使它不是最佳选择。


Btrfs 的吸引力之一是与卷管理器集成的文件系统所带来的更轻松的管理。要是在 LVM 之上运行，对于系统维护，仍然要对额外的卷管理器进行一些设置。同样，LVM 设置通常具有多个固定大小的逻辑卷，并具有独立文件系统。虽然 Btrfs 支持给定的计算机上的多个卷，但是许多不错的功能都需要单一卷具有多个子卷。如果每个 LVM 卷都有一个独立的 Btrfs 卷，则用户仍然需要手动管理固定大小的 LVM 卷。虽然能够收缩挂载的 Btrfs 文件系统的能力确实使处理固定大小的卷的工作变得更轻松。通过在线收缩功能，就无需启动 [实时镜像](https://fedoramagazine.org/reclaim-hard-drive-space-with-lvm/) 了。


在使用 Btrfs 的多设备支持时，必须仔细考虑逻辑卷的物理位置。对于 Btrfs 而言，每个逻辑卷都是一个单独的物理设备，如果实际情况并非如此，则某些数据可用性功能可能会做出错误的决定。例如，如果单个驱动器发生故障，对数据使用 RAID1 通常可以提供保护。如果实际逻辑卷在同一物理设备上，则没有冗余。


如果强烈需要某些特定的 LVM 功能，例如原始块设备或高速缓存的逻辑卷，则在 LVM 之上运行 Btrfs 是有意义的。在这种配置下，Btrfs 仍然提供其大多数优点，例如校验和和易于发送的增量快照。尽管使用 LVM 会产生一些操作开销，但 Btrfs 的这种开销并不比任何其他文件系统大。


### 总结


当尝试在 Btrfs 和 LVM-ext4 之间进行选择时，没有一个正确的答案。每个用户都有独特的要求，并且同一用户可能拥有具有不同需求的不同系统。看一下每个配置的功能集，并确定是否有令人心动的功能。如果没有，坚持默认值没有错。选择这两种设置都有很好的理由。




---


via: <https://fedoramagazine.org/choose-between-btrfs-and-lvm-ext4/>


作者：[Troy Curtis Jr](https://fedoramagazine.org/author/troycurtisjr/) 选题：[lujun9972](https://github.com/lujun9972) 译者：[Chao-zhi](https://github.com/Chao-zhi) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
[Fedora 33](https://fedoramagazine.org/announcing-fedora-33/) introduced a new default filesystem in desktop variants, [Btrfs](https://btrfs.wiki.kernel.org/index.php/Main_Page). After years of Fedora using [ext4](https://ext4.wiki.kernel.org/index.php/Main_Page) on top of [Logical Volume Manager (LVM)](https://man7.org/linux/man-pages/man8/lvm.8.html) volumes, this is a big shift. Changing the default file system requires [compelling reasons](https://fedoraproject.org/wiki/Changes/BtrfsByDefault). While Btrfs is an exciting next-generation file system, ext4 on LVM is well established and stable. This guide aims to explore the high-level features of each and make it easier to choose between Btrfs and LVM-ext4.

## In summary

The simplest advice is to stick with the defaults. A fresh Fedora 33 install defaults to Btrfs and upgrading a previous Fedora release continues to use whatever was initially installed, typically LVM-ext4. For an existing Fedora user, the cleanest way to get Btrfs is with a fresh install. However, a fresh install is much more disruptive than a simple upgrade. Unless there is a specific need, this disruption could be unnecessary. The Fedora development team carefully considered both defaults, so be confident with either choice.

## What about all the other file systems?

There are a [large number of file systems for Linux systems](https://man7.org/linux/man-pages/man5/filesystems.5.html). The number explodes after adding in combinations of volume managers, encryption methods, and storage mechanisms . So why focus on Btrfs and LVM-ext4? For the Fedora audience these two setups are likely to be the most common. Ext4 on top of LVM became the default disk layout in Fedora 11, and ext3 on top of LVM came before that.

Now that Btrfs is the default for Fedora 33, the vast majority of existing users will be looking at whether they should stay where they are or make the jump forward. Faced with a fresh Fedora 33 install, experienced Linux users may wonder whether to use this new file system or fall back to what they are familiar with. So out of the wide field of possible storage options, many Fedora users will wonder how to choose between Btrfs and LVM-ext4.

## Commonalities

Despite core differences between the two setups, Btrfs and LVM-ext4 actually have a lot in common. Both are mature and well-tested storage technologies. LVM has been in continuous use since the early days of Fedora Core and ext4 became the [default in 2009 with Fedora 11](https://docs.fedoraproject.org/en-US/Fedora/11/html/Release_Notes/index.html#sect-Release_Notes-Fedora_11_Overview). Btrfs merged into the mainline Linux kernel in 2009 and [Facebook uses it widely](https://facebookmicrosites.github.io/btrfs/docs/btrfs-facebook.html). SUSE Linux Enterprise 12 made it the [default in 2014](https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/#fate-317221). So there is plenty of production run time there as well.

Both systems do a great job preventing file system corruption due to unexpected power outages, even though the way they accomplish it is different. Supported configurations include single drive setups as well as spanning multiple devices, and both are capable of creating nearly instant snapshots. A variety of tools exist to help manage either system, both with the command line and graphical interfaces. Either solution works equally well on home desktops and on high-end servers.

## Advantages of LVM-ext4

![Show the relationship of LVM-ext4 filesystem to hard-drive partitions and mounted directories.](https://fedoramagazine.org/wp-content/uploads/2020/12/ext4-on-LVM.jpg)

[Structure of ext4 on LVM](https://gitlab.com/troycurtisjr/fedora-magazine-notes/-/blob/main/lvm-btrfs/ext4%20on%20LVM.svg)

The [ext4 file system](https://opensource.com/article/18/4/ext4-filesystem) focuses on high-performance and scalability, without a lot of extra frills. It is effective at preventing fragmentation over extended periods of time and provides [nice tools](https://man7.org/linux/man-pages/man8/e4defrag.8.html) for when it does happen. Ext4 is rock solid because it built on the previous ext3 file system, bringing with it all the years of in-system testing and bug fixes.

Most of the advanced capabilities in the LVM-ext4 setup come from LVM itself. LVM sits “below” the file system, which means it supports any file system. Logical volumes (LV) are generic block devices so [virtual machines can use them directly.](https://libvirt.org/storage.html#StorageBackendLogical) This flexibility allows each logical volume to use the right file system, with the right options, for a variety of situations. This layered approach also honors the Unix philosophy of small tools working together.

The [volume group](https://www.redhat.com/sysadmin/create-volume-group) (VG) abstraction from the hardware allows LVM to create flexible logical volumes. Each LV pulls from the same storage pool but has its own configuration. Resizing volumes is a lot easier than resizing physical partitions as there are no limitation of ordered placement of the data. LVM [physical volumes](https://www.redhat.com/sysadmin/create-physical-volume) (PV) can be any number of partitions and can even move between devices while the system is running.

LVM supports read-only and read-write [snapshots](https://tldp.org/HOWTO/LVM-HOWTO/snapshotintro.html), which make it easy to create consistent backups from active systems. Each snapshot has a defined size, and a change to the source or snapshot volume use space from there. Alternately, logical volumes can also be part of a [thinly provisioned pool](https://man7.org/linux/man-pages/man7/lvmthin.7.html). This allows snapshots to automatically use data from a pool instead of consuming fixed sized chunks defined at volume creation.

### Multiple devices with LVM

LVM really shines when there are multiple devices. It has native support for most [RAID levels](https://rhea.dev/articles/2018-08/LVM-RAID-on-Fedora) and each logical volume can have a different RAID level. LVM will automatically choose appropriate physical devices for the RAID configuration or the user can specify it directly. Basic RAID support includes data striping for performance ([RAID0](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_0)) and mirroring for redundancy ([RAID1](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_1)). Logical volumes can also use advanced setups like [RAID5](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_5), [RAID6](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_6), and [RAID10](https://en.wikipedia.org/wiki/Non-standard_RAID_levels#Linux_MD_RAID_10). LVM RAID support is mature because under the hood LVM uses the same [device-mapper (dm)](https://man7.org/linux/man-pages/man8/dmsetup.8.html) and [multiple-device (md)](https://man7.org/linux/man-pages/man4/md.4.html) kernel support used by [mdadm](https://fedoramagazine.org/managing-raid-arrays-with-mdadm/).

Logical volumes can also be [cached volumes](https://man7.org/linux/man-pages/man7/lvmcache.7.html) for systems with both fast and slow drives. A classic example is a combination of SSD and spinning-disk drives. Cached volumes use faster drives for more frequently accessed data (or as a write cache), and the slower drive for bulk data.

The large number of stable features in LVM and the reliable performance of ext4 are a testament to how long they have been in use. Of course, with more features comes complexity. It can be challenging to find the right options for the right feature when configuring LVM. For single drive desktop systems, features of LVM like RAID and cache volumes don’t apply. However, logical volumes are more flexible than physical partitions and snapshots are useful. For normal desktop use, the complexity of LVM can also be a barrier to recovering from issues a typical user might encounter.

## Advantages of Btrfs

![Show the relationship of Btrfs filesystem to hard-drive partitions and mounted directories.](https://fedoramagazine.org/wp-content/uploads/2020/12/Btrfs-Volume.jpg)

[Btrfs Structure](https://gitlab.com/troycurtisjr/fedora-magazine-notes/-/blob/main/lvm-btrfs/Btrfs%20Volume.svg)

Lessons learned from previous generations guided the features built into [Btrfs](https://btrfs.wiki.kernel.org/index.php/Main_Page). Unlike ext4, it can directly span multiple devices, so it brings along features typically found only in volume managers. It also has features that are unique in the Linux file system space ([ZFS](https://en.wikipedia.org/wiki/ZFS) has a similar feature set, but [don’t expect it in the Linux kernel](https://itsfoss.com/linus-torvalds-zfs/)).

### Key Btrfs features

Perhaps the most important feature is the checksumming of all data. Checksumming, along with copy-on-write, provides the [key method](https://btrfs.wiki.kernel.org/index.php/FAQ#Can_I_have_nodatacow_.28or_chattr_.2BC.29_but_still_have_checksumming.3F) of ensuring file system integrity after unexpected power loss. More uniquely, checksumming can detect errors in the data itself. Silent data corruption, sometimes referred to as [bitrot](https://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows-inside-next-gen-filesystems/), is more common that most people realize. Without active validation, corruption can end up propagating to all available backups. This leaves the user with no valid copies. By transparently checksumming all data, Btrfs is able to immediately detect any such corruption. Enabling the right [dup or raid option ](https://man7.org/linux/man-pages/man8/mkfs.btrfs.8.html#DUP_PROFILES_ON_A_SINGLE_DEVICE)allows the file system to transparently fix the corruption as well.

[Copy-on-write](https://en.wikipedia.org/wiki/Copy-on-write) (COW) is also a fundamental feature of Btrfs, as it is critical in providing file system integrity and instant subvolume snapshots. Snapshots automatically share underlying data when created from common subvolumes. Additionally, after-the-fact [deduplication](https://btrfs.wiki.kernel.org/index.php/Deduplication) uses the same technology to eliminate identical data blocks. Individual files can use COW features by calling *cp* with the [reflink option](https://btrfs.wiki.kernel.org/index.php/UseCases#How_do_I_copy_a_large_file_and_utilize_COW_to_keep_it_from_actually_being_copied.3F). Reflink copies are especially useful for copying large files, such as virtual machine images, that tend to have mostly identical data over time.

Btrfs supports spanning multiple devices with no volume manager required. Multiple device support unlocks data mirroring for redundancy and striping for performance. There is also experimental support for more advanced RAID levels, such as [RAID5](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_5) and [RAID6](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_6). Unlike standard RAID setups, the Btrfs *raid1 *option actually allows an odd number of devices. For example, it can use 3 devices, even if they are are different sizes.

All RAID and dup options are specified at the file system level. As a consequence, individual subvolumes cannot use different options. Note that using the RAID1 option with multiple devices means that all data in the volume is available even if one device fails and the checksum feature maintains the integrity of the data itself. That is beyond what current typical RAID setups can provide.

### Additional features

Btrfs also enables quick and easy remote backups. Subvolume snapshots can be [sent to a remote system](https://fedoramagazine.org/btrfs-snapshots-backup-incremental/) for storage. By leveraging the inherent COW meta-data in the file system, these transfers are efficient by only sending incremental changes from previously sent snapshots. User applications such as [snapper](http://snapper.io/) make it easy to manage these snapshots.

Additionally, a Btrfs volume can have [transparent compression](https://btrfs.wiki.kernel.org/index.php/Compression) and * chattr +c* will mark individual files or directories for compression. Not only does compression reduce the space consumed by data, but it helps extend the life of SSDs by reducing the volume of write operations. Compression certainly introduces additional CPU overhead, but a lot of options are available to dial in the right trade-offs.

The integration of file system and volume manager functions by Btrfs means that overall maintenance is simpler than LVM-ext4. Certainly this integration comes with less flexibility, but for most desktop, and even server, setups it is more than sufficient.

## Btrfs on LVM

Btrfs can [convert an ext3/ext4 file system in place](https://btrfs.wiki.kernel.org/index.php/Conversion_from_Ext3). In-place conversion means no data to copy out and then back in. The data blocks themselves are not even modified. As a result, one option for an existing LVM-ext4 systems is to leave LVM in place and simply convert ext4 over to Btrfs. While doable and supported, there are reasons why this isn’t the best option.

Some of the appeal of Btrfs is the easier management that comes with a file system integrated with a volume manager. By running on top of LVM, there is still some other volume manager in play for any system maintenance. Also, LVM setups typically have multiple fixed sized logical volumes with independent file systems. While Btrfs supports multiple volumes in a given computer, many of the nice features expect a single volume with multiple subvolumes. The user is still stuck manually managing fixed sized LVM volumes if each one has an independent Btrfs volume. Though, the ability to shrink mounted Btrfs filesystems does make working with fixed sized volumes less painful. With online shrink there is no need to boot a [live image](https://fedoramagazine.org/reclaim-hard-drive-space-with-lvm/).

The physical locations of logical volumes must be carefully considered when using the multiple device support of Btrfs. To Btrfs, each LV is a separate physical device and if that is not actually the case, then certain data availability features might make the wrong decision. For example, using *raid1* for data typically provides protection if a single drive fails. If the actual logical volumes are on the same physical device, then there is no redundancy.

If there is a strong need for some particular LVM feature, such as raw block devices or cached logical volumes, then running Btrfs on top of LVM makes sense. In this configuration, Btrfs still provides most of its advantages such as checksumming and easy sending of incremental snapshots. While LVM has some operational overhead when used, it is no more so with Btrfs than with any other file system.

## Wrap up

When trying to choose between Btrfs and LVM-ext4 there is no single right answer. Each user has unique requirements, and the same user may have different systems with different needs. Take a look at the feature set of each configuration, and decide if there is something compelling about one over the other. If not, there is nothing wrong with sticking with the defaults. There are excellent reasons to choose either setup.

## Sergey

I use KVM on servers where all the virtual disks are on the LVM(XFS). BtrFS can already do that ?

## Troy Curtis Jr

If you mean that the virtual disks use an LVM volume group and allocate out of that, not exactly. With Btrfs you’d have a directory for file-based virtual disk images. You’d also want to disable copy-on-write in that disk directory, since large image files like that don’t have good performance with CoW (from what I have read). This can be done with the “chattr +C” command.

But note that that is a fairly advanced usage of LVM and a nice one at that. So it is entirely reasonable to keep using LVM, allowing for nice management of generic block devices, and using a logical volume to host your Btrf volume.

## RandomInternetDude

I usully install fedora with LVM+ext4 with LUKS2 encryption.

I didn’t see a flag for encryption when choosing BTRFS in the installer.

How do I install Fedora with BTRFS and full disk encryption?

## Chris

I followed this tutorial, and it seems to work:

https://mutschler.eu/linux/install-guides/fedora-btrfs/

## red chili

So do I and I therefore also missed that option within Anaconda (the installer), especially when one wants to not only use BTRFS within LUKS2 but also use some subvolumes (I prefer to put /home into a @home subvol as well as some others).

It ended up working fine but involved quite some try and error, manually partitioning LUKS2 and BTRFS and after the installer has finished manually moving parts of the fs-tree into the respective subvolumes while mounting/unlocking the LUKS2 volume through booting via live-cd.

## Esc

Great job. Is there any info about stable raid5 in btrfs?

## Jesse Pollard

Biggest problem btrfs has is that it STILL has not got reliable raid support – “mostly OK” doesn’t cut it.

## Alan Diggs

Specifically RAID 6/5. While it is actually usable and falls back to journaling to address some of the write hole issues, it’s probably best to avoid using in production until it’s actually marked as stable. RAID 0/1/10 are ready, which TBF, is more important in general for desktops. As Workstation targets desktops, this is good news.

## Troy Curtis Jr

Yeah that is definitely true. Though mdraid or raid5/6 support with LVM can be used with Btrfs on top. The only downside there is that there isn’t the all-in-one command

to do all management from. Otherwise, it is a perfectly valid option.

## Norbert J.

Great article, many thanks!

I also wonder whether I should migrate from LVM-ext4 to Btrfs and appreciate the checksum feature, but I usually have the last 2 Fedora releases installed in parallel, with the option for yet another distro in mind. Although this probably can also be achieved with Btrfs subvolumes, I believe LVM to provide much better protection against accidental loss of the old OS when installing the new one.

## Troy Curtis Jr

Thanks!

blushesI think your usage is pretty advanced, so it seems entirely reasonable to keep using LVM to help separate the multiple OS versions and use Btrfs on top of one of the logical volumes. This is in fact the path I have chosen. The main upside to an all-in Btrfs setup is easier management, but when you start managing side-by-side versions of the OS, you are already past that level of easy 😉

## Sally

With the all benefits that’s been said of Btrfs, why fedora still uses ext4 on /boot by default with F33?

And what is the best filesystem for ‘/boot’?

## Stephen Snow

The reason for that is to do with the boot loader more than the specific filesystem, except that I am uncertain if Grub2 has a btrfs driver as of yet, so /boot being EXT4 is not a real btrfs issue.

## Chris Murphy

Mainly to avoid regression in a nice feature hide the GRUB menu.

More detail in Ask Fedora discussion.

## Cédric

Interresting

In LVM/ext4, it s simple to extends VG by adding Disks. Same things when a disk need to be change.

btrfs seems to integrate lvm on the FS feature

If I have unterstood, you could use RAID0 to extends an existing FS Full but what s happen if you need change a device with data? when you are in raid0 mode and use for example 3 devices? In LVM you could migrate data between device.

What s happen if / is full? Do you have always access for launching some cleaning? like 10% reserved space in ext4. Ok it s too important when you use a big FS, but the System continu to work.I m not sure that this is manage by brtfs.

I think that brtfs must to be more mature with more tools for admin to integrate standard feature basicaly like

Add/Extend/Remove/… device with one command only without use raid feature.

But it s my opinion 🙂

If someone have an experience in production with BRTFS with standard issue, Full FS, disk failures,…

Regards,

## Mica

Don’t use brtfs in production. COW is a performance killer and btrfs balance and disk fulls due to snapshots have caused downtime to dozens of vms. The only thing btrfs is good at is selling more cloud vender disk as you have to way over provision. Simple disks and xfs or ext4 is the most stable setup. Back your disk stores on NetApp filers and you are good to go

## Jos

Of you are ok with silent data corruption ext4 is great, ot wont bother telling you your priceless family photos are damaged. If you care about your data, I would recommend btrfs. The performance differences are a wash and you get a great many extra benefits from the snapshots and easier backups to more flexible raid setups.

As a reply to Cédric, you are in luck, btrfs handles those situations better than moat setups – it is extremely flexible in how you can add and remove drives and modify volumes on the fly, a major advantage over a lvm/extremely or ZFS setup.

## Troy Curtis Jr

Btrfs seems perfectly fine to use in production, Facebook is continuing to expand their own own usage for example. Of course, like any infrastructure there are tradeoffs in different scenarios. Snapshots are a fantastic tool, but they must be managed. Taking a snapshot freezes that data, that’s the point! But that means you must be very deliberate about clean ups. And certainly if you have a huge churn in your data that is being snapshot, you will consume additional space more rapidly as new copies of the data are created during write operations.

There certainly seem to be cases where COW really hurts performance, large binary files such as VM disk images is the classic example. It is prudent to do targeted disabling of COW to be sure. However, COW also enables some really nice features, especially around handling of snapshots and the integration with the checksuming to detect otherwise silent data errors.

## Benjamin Smith

My comments are based on ZFS…

CoW was a life saver for our situation! We had over 500 million files in a large, 50/50 read/write distributed that we had to back up nightly per SLA and rsync just wasn’t cutting it any longer – just the discovery phase was taking over 24 hours and hammering performance.

Switched to ZFS, RAIDZ zvols of 6 drives RAIDZ2, 24 drives total, in systems having 32 GB of RAM and 24 Xeon cores each. Backup time dropped from almost 36 hours to under 1 over Gbit connection, and system load average dropped through the floor.

I don’t trust BTRFS after getting burned a few times, and have been using ZFS ever since with wonderful reliability, although I don’t use ZFS on root – only hosted data partitions. Admittedly, the BTRFS burns were long ago, but involved RAID and here it’s years and years later and it’s still not fixed.

## Chris

After a week of testing Btrfs on my laptop, I can conclude that there is a noticeable performance penalty vs Ext4 or XFS. Using Btrfs, just expanding a zip file and trying to immediately enter that new expanded folder in Nautilus, I am presented with a “busy” spinning graphic as Nautilus is preparing to display the new folder contents. This never happens for me with Ext4 or XFS. And it’s a fast M.2 drive on very good hardware. That said; this wait could be completely worth it. If the added data integrity protections offered by Btrfs are to be believed, then a desktop user would be better served at least giving it a shot. And if you have not been using Linux for the past decades, you’re never going to notice the slight performance regression vs Ext4 or XFS anyway, as you have no point of reference. As for me, I’m back to XFS. I have backup practices in place that do not require file-system level roll-backs, so it is doubtful that I would even use Btrfs for what it is intended to provide. I do fully appreciate all of the hard work that is going into Btrfs and Fedora. In the future when I have the time, I will begin to migrate to my backup procedures to take advantage of what Btrfs has to offer. Until then, I’m sticking to XFS backed up to ZFS RAID on TrueNAS.

## Leslie Satenstein, Montreal,Que,Canada

With zfs (single disk lvm) you can almost watch the electrons move as your command gets processed. I used xfs, migrated to btrfs, and am testing openzfs. For a desktop system the latter two are overkill. Btrfs is about 2x speed of zfs for my config.

my config

2700x 16gigs ram, 120 gig SSD (zfs) m.2 1tb for btrfs. System is underutilzed.

## Gregory Bartholomew

One thing to set on zfs that can improve performance is “ashift=12” (2^12=4K sectors). Without that setting, zfs defaults to 512 byte sectors (modern SSDs are optimized for 4K I/O). I also like to use the “edonr” checksum algorithm. Setting “relatime=on” can also help. On Fedora you will want “xattr=sa” so all the SELinux extended attributes will be stored efficiently. Also, “acltype=posix” and “dnodesize=auto” are a good idea. Unfortunately (or perhaps fortunately depending on how you look at it) zfs has a

LOTof tunables (and if you really want to get under the hood, have a look at “modinfo zfs”). With so many configurable options and varying defaults, one cannot really just say “btrfs is better than zfs” or vice versa.## David Ruedeman

I was thinking the similar thing. Interesting that RH went from “we won’t consider btrfs” to including it as standard in version 33. Suse has included btrfs as standard. HOWEVER, they only support a subset of btrfs. They do not support, for example, native btrfs RAID, integrated volume management ,compression and encryption. Moreover, they recommend to use it only for root and use xfs for other volumes. Also they have janitor processes running btrfs balance , btrfs scrub etc on a regular basis. I do not see this on Fedora 33. Is this just sloppiness on Fedora’s part or is there some improvements in the later kernels that obviate the need for janitor processes.

## Timo

Great article. There is also another significant difference between Btrfs and LVM-ext4 setups. LVM supports encryption while Btrfs doesn’t yet. If you have to meet a data at rest requirement you can’t conform with it with Btrfs alone.

## Alex

It is possible to place a BTRFS file system on a LUKS volume. Lets say you have a disk at /dev/sdb with a single partition /dev/sdb1 spanning the entire disk. You can then do the following:

cryptsetup luksFormat /dev/sdb1

cryptsetup luksOpen /dev/sdb1 mydata

mkfs.btrfs -L mydata1 /dev/mapper/mydata

mount /dev/mapper/mydata /mydatamntpoint

## Chris Murphy

Anaconda, Fedora’s installer, will place Btrfs on LUKS/dm-crypt. It’s as simple as checking “Encrypt my data” in Figure 12 screenshot, in the install guide.

Custom it’s slightly trickier to find, you need to set it on the entire Btrfs volume rather than at the mount point. The encrypt option is found in the Volume>Modify submenu, Figure 21 of the install guide shows it, it’s center-right in the screenshot.

## red chili

Thanks for this insightful writeup which I wish I had come across earlier (yes, i know its just been published) as it answers many fundamental questions one might wonder about in regards to this new default.

One think that I think should be explicitly mentioned that the new default only affects DESKTOP-spins, fedora 33 SERVER will per default typically still use LVM + XFS but as @chrismurphy has stated in his reply to my issue posted at https://ask.fedoraproject.org/t/cannot-mount-btrfs-subvolume-to-home-from-within-lvm/10805 , this can be altered by choosing ‘custom’ and BTRFS as partition scheme during installation.

## svsv sarma

Thank you for the attempt at explaining/clarifying/recommending the new BTRFS. But the more you explain the more I am confused. Are you aware of any feed back from the existing users of Fedora 33 with the default BTRFS? That is very helpful really and decisive. Presently I am using Fedora 33 in live cd due to the dilemma and avoided upgrading lest it should spoil my mood. However I will install Fedora 33 BTRFS soon as recommended. If only the secret of Fedora 33 btrfs is not revealed!!

## Stephen Snow

I have used btrfs from Fedora 33 rawhide on with Fedora Silverblue. I have 2 SSD setup as raid1 for the subvolume ‘/’ and a spinning disk setup as subvolume ‘/home’. I created a sub-volume on my spinning disk when I was running Fedora 32 SB to do a snapshot of my home dir prior to fresh installing F33 rawhide SB onto my system. I later mounted this snapshot and restored my home dir after fresh install. So far I have upgrade to release version F33 SB with all of the updates in between with no file system issues.

## Alan Diggs

“Are you aware of any feed back from the existing users of Fedora 33 with the default BTRFS? ”

Here’s a Reddit thread from some users!

https://www.reddit.com/r/Fedora/comments/k3toqr/how_is_btrfs_going_for_everyone_so_far

## Leslie Satenstein, Montreal,Que,Canada

When the experts stated that btrfs was the default for Fedora 33, I took their advice and converted most of my partitions to btrfs. I added compression, as an advantage, which allowed me to conserve some disk space. It has worked out well for me.

There are some features of btrfs such as snapshots and perhaps some other tools that I want to explore in order to do off-site backups using an external hard disk.

But at the same time, I am researching openzfs and finding openzfs to be disappointing and great at the same time. The disappointment is the licensing. It is not gpl2* licensed and therefore not available to RedHat or derivatives. The great part is that it is a logical volume manager and a superior btrfs solution all rolled up into one. Hopefully, oneday soon, openzfs can be dual licensed under cddl and gpl2, making it available to Fedora.

I must congratulate the author on this fine posting. It is well organized and reads well. It confirms my decision to standardize, all my data partitions to be btrfs organized.

Happy New Year to all.

## Jos

Sorry, zfs will never be fixed licens-wise, but it doesn’t do anything btrfs doesn’t and being out of the kernel means it is perpetually behind. It is no loss.

## leslie Satenstein

Grub and btrfs. One serious issue for me is grub’s support of multi-btrfs based systems.

I use fedora 33 with btrfs, and I have a test version of Fedora33 (btrfs) and Rawhide(btrfs). The grub2-mkconfig recognizes all three, but only creates entries for the host Fedora 33.

I have to resort to “chain load” options to be able to boot the secondary distributions. If you only have the one Fedora33 with btrfs, the grub.cfg problem would be a “no-issue”.

## József Dezső

I currently prefer BTRFS.

But if the system and installer supported ZFS, I would rather choose it.

## Bill Chatfield

For a workstation, Btrfs is unnecessary and LVM-ext4 is slower than plain ext4. Just use plain ext4 and store your data in the cloud with Dropbox and/or git. If Gnome Shell crashes your machine, all you data is safe in Dropbox. Just reinstall Fedora or use a different machine. If all your data is in the cloud, your workstation becomes just a replaceable terminal.

## oldkid

But the author mentioned that btrfs would benefit SSD life, I think it must be a good thing. Other than that, I too prefer your method. I just back up important files to other external hard drives without messing with the file system at all. I have enough programming background but for some reason I always suck at dealing with the file system, group, volume stuff. No matter how many tutorials I read, I’d always make one or two mistakes in the process, which unsurprisingly ends up with me in grief and misery for days.

## Edson

Does btrfs suffer of sane problema as ext4 on “outage inodes” (out of disk space even having space) when running a filesystem with millions of files? Xfs currently doesn’t suffer on this problem.

## Chris Murphy

Btrfs and XFS dynamically allocate inodes, rather than being created with a fixed number at mkfs time as it is on ext4. Further, Btrfs subvolumes are an independent file tree with their own pool of inodes. Each subvolume can contain 264 inodes and each Btrfs file system can contain 264 subvolumes (snapshots are also subvolumes).

## Chris Murphy

Nice, WP doesn’t support “sup” tag. OK 2^64 inodes and 2^64 subvolumes. 😀

## Connor The Poomp

Why are you calling a file system that is over a decade old “next gen” …?

## Jos

Because it is next gen compared to ext4 and LVM, bringing many new features and improved reliability (like not silently letting your data corrupt but catching and, if you use RAID, fixing it).

## Troy Curtis Jr

Jos is right on. Filesystems are naturally very conservatively evolving code bases as they are so critical to computing, so it isn’t surprising it has been more than 10 years before we are really getting comfortable pulling it in for default use.

The “next generation” is less about age and “newness”, but instead more about paradigm. There are many filesystems, but most are based around the same basic ideas with incremental tweaks. Next gen filesystems like Btrfs and ZFS rethink what a filesystem can do, pulling in novel features and integrating capabilities found previously only in volume managers. Even one of the key developers around Ext4 pointed out that it was just a stop-gap measure, piling on older file system principals, and biding time for Next gen systems like Btrfs to mature. https://arstechnica.com/information-technology/2009/04/linux-collaboration-summit-the-kernel-panel/

## Mark

One of the more useful features of LVM is being able to vgexport/vgimport allowing VM or SAN logical disks and even physical disks to be easily moved between machines and retain all the logical volume layouts used.

A quick search on a brtfs equivalent only found the below which indicates brtfs works with whole disks. It basically says move the disks and mount them, that implies things like quotas are stored on the disks similar to an lvm exported volume group which if true is nice.

https://btrfs.wiki.kernel.org/index.php/UseCases#Are_there_a_similar_commands_in_BTRFS_like_ZFS_export.2Fimport.3F

When there are disk issues there are likely to be more google answers for lvm/ext4 than for brtfs so lvm/ext4 is a better fit for new users.

Also resizing filesystems on LVs and the underlying filesystems on them is fairly trivial. brtfs quotas may enforce sizes similar to LVs but are not nearly as intuitive as under zfs.

As for zfs I was using that from the 2006/06 solaris x86 release that finally got it working; personally I don’t see brtfs as an improvement over what was available then. However as zfs licensing does prevent it being part of Linux by default anyone that worries about bitrot (which really does occur) should consider brtfs for its checksum facility to hopefully prevent that.

Portability may be a consideration as well. ext4 has been around for a long time and there are windows utilities to read ext4 filesystems, I’m not aware of any for brtfs although there may be some. If you have a dual boot system you may want ext4.

Also the mediawiki entry raises a few questions. From the below link

https://en.wikipedia.org/wiki/Btrfs

The ‘dd’ command is often references in google search results as a way of backing up data on ohysical or lvm filesystems, interesting that using dd on a brtfs filesystem wil result in data loss.

That wikipedia entry also states

In August 2017, Red Hat announced in the release notes for Red Hat Enterprise Linux (RHEL) 7.4 that it no longer planned to move Btrfs, which had been included as a “technology preview” since RHEL 6 beta, to a fully supported feature, noting that it would remain available in the RHEL 7 release series. Btrfs was removed from RHEL 8 in May 2019.

In 2020, Btrfs was selected as the default file system for Fedora 33.

Therefore one must wonder why brtfs is being pushed in F33. Of course you cannot believe everything you read on the internet and RedHat may be filly embracing brtfs.

## bruce sm

I used btrfs, Then it tried to kill all my data. I thought once was just a version problem. TWICE? Now i use xfs or ext4. XFS survived a lightning strike. It will be a very long time before i trust btrfs again, in fact count that as never again.

## chris

same it tried to wreck 2tb of a database…

2tb, i say that seriously my database is roughly 2tb large and there were so many missing or extra semaphores that it was overflowing because of i had to revert to backup and say like you did… never again.

## Chris

Btrfs caused me all sorts of issues with high input-output mariadb on sata hdd

I’m waiting till all the kinks are ironed out.

## Troy Volin

Super article. Lots of useful tidbits dangled along the way, while staying very focused.

Interesting that you say you’ve chosen (for yourself) to stick with btrfs-on-LVM.

Seems like there will always be cases when you may benefit from that flexibility at the lower level. LVM for swap, LVM to have a distinct high-performance-unencrypted btrfs volume, etc.

And since it supports shrinking mounted volumes (!!!) you can dump almost all your space on your primary btrfs, and shrink the FS and LV later if needed.

Now I have a plan! Thanks!

## Troy Curtis Jr

I proposed the article partly to document my own journey of learning. Honestly when I started my research I had settled on sticking with LVM+ext4. I had also come to the conclusion that I

shouldn’tdo Btrfs on LVM. As a result I didn’t convert my desktop when I installed Fedora 33, even though I did a fresh install. After my research I got super excited about Btrfs and could barely stay focused on finishing my article because I wanted to convert my systems. I also learned that I still wanted some of the features and flexibility of LVM, and that it was perfectly reasonable to put Btrfs on top as long as you accepted that Btrfs wouldn’t be the one-stop-shop.Now my new laptop has LVM + LUKS2 + Btrfs. I have already taken advantage of sending snapshots and transparent compression, it has been really awesome so far.

Good luck on your file system journey!

## NuBz

I don’t use lvm and have no need to get all fancy with my file system.

EXT4 works fine for everything I do.

## Olivier

Does anyone have experience or some numbers about the performance of BTRFS on a spinning disk ?

When upgrading to Fedora 33, I had a spare partition on my old laptop; decided to try a fresh install with BTRFS.

The first time I did a

, it took almost 2 hours to get done. And each time I tried to use dnf, I had to be really patient. I first thought about a DNF problem, but I decided to give XFS a try (the old system partition is using a good old ext4).

All I have to say is that with XFS, my computer and DNF are back to normal speed (not fast for that old machine, but not extra slow).

I suspect that BTRFS is not behaving correctly on a spinning disk, but maybe it’s just a configuration problem. But what to change ?

## Matthew

Nice to hear! I’ve been using btrfs for multiple drives now for 4 years and it’s been rock solid. No need to mess with gparted and complicated LVM schemes anymore. Welcome to the Linux filesystem of the future.