4 ms·

A btrfs versus ZFS comparison probably deserves a blog post of its own, but I will try to address your question. I wrote the following on this topic last year:

by ryao 12y ago

A btrfs versus ZFS comparison probably deserves a blog post of its own, but I will try to address your question. I wrote the following on this topic last year: https://groups.google.com/d/msg/funtoo-dev/g9OY_vqVpCM/VTKF8Ef9ab4J https://groups.google.com/d/msg/funtoo-dev/g9OY_vqVpCM/VTKF8... However, significant time has passed and it requires some corrections to be current: 1. I have not heard of any recent data corruption issues in btrfs, although I have not looked into them lately. 2. btrfs now has experimental RAID 5/6 support, but is neither production ready nor as refined as ZFS' raidz. 3. I should have said "inline block-based data deduplication". You can (ab)use reflinks to achieve a file-level data deduplication in btrfs, but it is not quite the same. btrfs now has a bedup tool that makes using reflinks somewhat easier now: https://btrfs.wiki.kernel.org/index.php/Deduplication https://btrfs.wiki.kernel.org/index.php/Deduplication 4. btrfs now has some kind of incremental send/recv operation. However, it is not clear to me how it handles consistency issues from having "write-able snapshots": https://btrfs.wiki.kernel.org/index.php/Incremental_Backup https://btrfs.wiki.kernel.org/index.php/Incremental_Backup 5. Illumos' ZFS implementation is now able to store small files in the dnode, which is improves its efficiency when storing small files in a manner similar to btrfs' block suballocation. This feature will likely be in ZoL 0.6.4. Aside from those corrections, what I wrote in that mailing list email should still be relevant today. However, there are a few advantages that ZFS has over btrfs that I recall offhand that I do not see here there or in nisa's reply: 0. ZFS uses 256-bit checksums with algorithms that are still considered to be good today. btrfs uses checksum algorithms that are known to be weak. In specific, btrfs uses CRC32 on 32-bit processors and CRC64 on 64-bit processors. CRC32 is the same algorithm used by TCP/IP. Its deficiencies are well documented: http://noahdavids.org/self_published/CRC_and_checksum.html http://noahdavids.org/self_published/CRC_and_checksum.html I have not examined CRC64, but I am not particularly confident in it. btrfs should have room in its on-disk data structures that would allow it to implement 256-bit checksums in a future disk format extension, but until then, its checksum implementations are vastly inferior. 1. The ztest utility that I described in the blog allows ZFS developers to catch issues that would have otherwise gone into production and debug them from userland. No other filesystem has something like quite like it. 2. ZFSOnLinux is the only kernel filesystem driver that is kernel version-independent, so if you are unable to upgrade your kernel, you can still get fixes. The inability of people to always update their kernels is an issue Linus mentioned at LinuxCon North America 2014. 3. The CDDL gives the ZFSOnLinux a patent grant for the ZFS patent portfolio. This is something that btrfs does not have and will likely never have unless Oracle decides to provide one. Consequently, Oracle is the only company in the world that I know is able to ship products incorporating the btrfs source code without being at risk should btrfs infringe on one of the dozens if not hundreds of patents in the ZFS patent portfolio. A small subset of them can be accessed from the Jeff Bonwick Wikipedia page: https://en.wikipedia.org/wiki/Jeff_Bonwick https://en.wikipedia.org/wiki/Jeff_Bonwick

ScottBurson 12y ago
I got the impression somewhere that btrfs RAID 5/6 support allows, or will allow, new devices to be added to an existing RAID group. That's an important feature for home and small business users. Having to replace every drive in a RAID group to grow it, as ZFS requires, is painful and expensive. Fortunately, drives are cheap enough these days that you can just way oversize your pool to begin with. But anyone switching to ZFS should be aware of the need to do this.
- voltagex_ 12y ago
  Can you link to anything about oversizing the pool? I think I vaguely remember a trick with creating a sparse file and adding that to the pool until you can replace that with a drive.
- cmurf 12y ago
  You can add/delete devices from raid5/6 volumes now. The raid5/6 code is still experimental, in particular while detected problems are fixed on-the-fly to userspace, the fixes aren't written back to drives. That limitation applies to normal usage and scrubbing. A balance detects and fixes these. Also the determination of a drive being "faulty" (in the md/mdadm sense) and how this gets communicated to userspace isn't in place. If it's in place for ZoL (?) that'd be a considerable difference, a bigger one than checksum algorithms in my opinion.
cmurf 12y ago
Metadata/data checksums are CRC-32C on all platforms and is per 4KB fs block. And ext4's (optional) checksumming also uses it. TCP is 16-bit and not CRC, although ethernet makes use of CRC-32. While SHA-2 is a cryptographic function and CRC-32C is not, and therefore inferior, as a checksum in the context of mostly but not entirely trusted hardware is adequate. It's also fast to the degree on modern hardware there's no point using nodatasum to disable it. Even 32-bit hardware handles it. Btrfs send/receive snapshots are read-only. So you first take a read-only snapshot, send it and upon receive it's read-only. To make it rw, snapshot it (without -r), and optionally delete the ro snapshot. I agree the kernel currency issue to get more urgent fixes is a problem for making filesystem usage friendly, in particular while development is heavy and backporting is non-trivial.

by ryao 12y ago

ScottBurson 12y ago

I got the impression somewhere that btrfs RAID 5/6 support allows, or will allow, new devices to be added to an existing RAID group. That's an important feature for home and small business users. Having to replace every drive in a RAID group to grow it, as ZFS requires, is painful and expensive. Fortunately, drives are cheap enough these days that you can just way oversize your pool to begin with. But anyone switching to ZFS should be aware of the need to do this.

voltagex_ 12y ago
Can you link to anything about oversizing the pool? I think I vaguely remember a trick with creating a sparse file and adding that to the pool until you can replace that with a drive.
cmurf 12y ago
You can add/delete devices from raid5/6 volumes now. The raid5/6 code is still experimental, in particular while detected problems are fixed on-the-fly to userspace, the fixes aren't written back to drives. That limitation applies to normal usage and scrubbing. A balance detects and fixes these. Also the determination of a drive being "faulty" (in the md/mdadm sense) and how this gets communicated to userspace isn't in place. If it's in place for ZoL (?) that'd be a considerable difference, a bigger one than checksum algorithms in my opinion.

cmurf 12y ago

Metadata/data checksums are CRC-32C on all platforms and is per 4KB fs block. And ext4's (optional) checksumming also uses it. TCP is 16-bit and not CRC, although ethernet makes use of CRC-32. While SHA-2 is a cryptographic function and CRC-32C is not, and therefore inferior, as a checksum in the context of mostly but not entirely trusted hardware is adequate. It's also fast to the degree on modern hardware there's no point using nodatasum to disable it. Even 32-bit hardware handles it. Btrfs send/receive snapshots are read-only. So you first take a read-only snapshot, send it and upon receive it's read-only. To make it rw, snapshot it (without -r), and optionally delete the ro snapshot. I agree the kernel currency issue to get more urgent fixes is a problem for making filesystem usage friendly, in particular while development is heavy and backporting is non-trivial.