An Exciting Btrfs Update With Encoded I/O, Fsync Performance Improvements

[R41N3R]

Imagine there would be a btrfs news without someone telling you about zfs ;-)

[Paradigm Shifter]

skeevy420 and others: I'd like to know your setup for partitioning etc... You mentioned your root is EXT4 and you use ZFS for others. I'd appreciate if people can elaborate. Thanks!

I'm a relative newcomer to ZFS (generally preferring more mature filesystems like ext4 or XFS) so am still finding my way, but on the systems I'm currently running ZFS (all two of them...) I use ext4 for /root and /home, ZFS with RAID-Z1 on three SATA SSDs for "fast" data, RAID-Z1 or Z2 across either 4 or 6 high capacity HDDs for "slow" data. It's been well behaved enough that I will probably expand ZFS to a few other systems as time permits, and get more adventurous with what I do. It was incredible easy to set up and so far has coped with the one time I managed to run out of RAM (on an 1.5TB system... oops...) gracefully (read: I didn't lose any data).

[intelfx]

Things ZFS can do BTRFS can't: exporting space as a block device, parity RAID, convert a folder into a dataset, have nice tools.

ZFS has the ability to expose space in the pool as a block device. Creating an 8GB ZFS volume is analogous to creating an 8GB logical volume with LVM. BTRFS doesn't have this ability.

There absolutely is, it just doesn't have a fancy overhyped name. Linux had support for creating loop devices for ages.

[darkbasic]

"The Btrfs VFS code now allows reflinks and deduplication from two different mounts of the same file-system"

I can't believe it finally happened!

[mether]

At the end of the day, ZFS is used for huge storage arrays of mission critical data in production. Nobody in their right mind would do that with BTRFS.

This is an incorrect assertion. https://btrfs.wiki.kernel.org/index....oduction_Users

[rleigh]

There absolutely is, it just doesn't have a fancy overhyped name. Linux had support for creating loop devices for ages.

Loop devices are not even close to ZFS zvols in terms of the features offered. They aren't just exposing a file as a device node. They are based on the ZFS DSL layer just like ZFS datasets, supporting nearly all of the properties you can set on datasets such as copies=n, compression, encryption, logbias etc. And being based on the DSL they support copy-on-write transactions just like dataset writes, so you can snapshot them, clone them, send/recv them etc., just like datasets. You can use them as the backing storage of virtual machines and then continuously and transparently snapshot them and offload the VM state while it's running, for example. Or clone it and fire up a new VM based on the old one, all while the old one is running. You can't do that with loopback devices.

[NobodyXu]

Loop devices are not even close to ZFS zvols in terms of the features offered. They aren't just exposing a file as a device node. They are based on the ZFS DSL layer just like ZFS datasets, supporting nearly all of the properties you can set on datasets such as copies=n, compression, encryption, logbias etc. And being based on the DSL they support copy-on-write transactions just like dataset writes, so you can snapshot them, clone them, send/recv them etc., just like datasets. You can use them as the backing storage of virtual machines and then continuously and transparently snapshot them and offload the VM state while it's running, for example. Or clone it and fire up a new VM based on the old one, all while the old one is running. You can't do that with loopback devices.

Doesn't loopback device just act like a regular file?

Thus, the compression is applied as usual, same for CoW.

As for file cloning, you can do that using cp reflink.

[intelfx]

Loop devices are not even close to ZFS zvols in terms of the features offered. They aren't just exposing a file as a device node. They are based on the ZFS DSL layer just like ZFS datasets, supporting nearly all of the properties you can set on datasets such as copies=n, compression, encryption, logbias etc. And being based on the DSL they support copy-on-write transactions just like dataset writes, so you can snapshot them, clone them, send/recv them etc., just like datasets. You can use them as the backing storage of virtual machines and then continuously and transparently snapshot them and offload the VM state while it's running, for example. Or clone it and fire up a new VM based on the old one, all while the old one is running. You can't do that with loopback devices.

More buzzwords.

In btrfs, you just create the backing file on a separate subvol. Bam, problem solved. No buzzwords needed.

[skeevy420]

Do you use EXT4 for your root and ZFS for other partitions? Can you explain a bit more and share how your hard disk structure is? Thanks!

Sorry, been away for a few days and I have over 2000 notification in my inbox here.

Yes. I'm currently using use the standard Manjaro ext4 setup and systemd mounts my ZFS stuff under /zeta/blah/yada. Unless I'm trying some esoteric setup out, my standard install method is to just go with the distribution defaults and install a zfs-dkms package. Due to using the dkms packages, if I'm using a distribution like Fedora or Arch that updates the kernel faster than OpenZFS has releases I'll also install a linux-lts package or compile my own so I don't upgrade and lose access to my non-root data (I did the same thing a decade ago when I had my last Nvidia GPU -- I consider it good practice to have a backup kernel when I use and rely on out of tree modules).

My current disk structure is Linux on a 480GB SDD, a ZFS zraid using 3 4TB HDDs, and a 1TB NVMe with Windows that hasn't been booted in a month or so. I've been considering wiping Windows and using that disk to hack together SteamOS on a ZFS root.

The way I see it: Valve has the January Arch ISO on their mirror. I reckon I could just use that ISO, change the Arch repos to Valve's, add some keyrings, do a standard Arch install, add some SteamOS pakcages, and BAM: SteamOS 3.

Here's my actual ZFS mountpoints to give you an idea of how I use it for my desktop stuff:

NAME                         PROPERTY     VALUE                   SOURCE
zeta                         mountpoint   /zeta                   default
zeta                         compression  lz4                     local
zeta/layer                   mountpoint   /zeta/layer             default
zeta/layer                   compression  lz4                     inherited from zeta
zeta/layer/documents         mountpoint   /zeta/documents         local
zeta/layer/documents         compression  zstd-19                 local
zeta/layer/games             mountpoint   /zeta/games             local
zeta/layer/games             compression  lz4                     inherited from zeta
zeta/layer/games/emulation   mountpoint   /zeta/games/emulation   local
zeta/layer/games/emulation   compression  zstd-19                 local
zeta/layer/games/pc          mountpoint   /zeta/games/pc          local
zeta/layer/games/pc          compression  lz4                     inherited from zeta
zeta/layer/games/pc/windows  mountpoint   /zeta/games/pc/windows  local
zeta/layer/games/pc/windows  compression  lz4                     inherited from zeta
zeta/layer/music             mountpoint   /zeta/music             local
zeta/layer/music             compression  zstd-19                 local
zeta/layer/pictures          mountpoint   /zeta/pictures          local
zeta/layer/pictures          compression  zstd-19                 local
zeta/layer/programs          mountpoint   /zeta/programs          local
zeta/layer/programs          compression  lz4                     inherited from zeta
zeta/layer/programs/linux    mountpoint   /zeta/programs/linux    local
zeta/layer/programs/linux    compression  lz4                     inherited from zeta
zeta/layer/programs/storage  mountpoint   /zeta/programs/storage  local
zeta/layer/programs/storage  compression  zstd-19                 local
zeta/layer/programs/windows  mountpoint   /zeta/programs/windows  local
zeta/layer/programs/windows  compression  lz4                     inherited from zeta
zeta/layer/projects          mountpoint   /zeta/projects          local
zeta/layer/projects          compression  lz4                     inherited from zeta
zeta/layer/videos            mountpoint   /zeta/videos            local
zeta/layer/videos            compression  zstd-19                 local

As you can see I alternate between speedy LZ4 and Jesus Christ Why ZSTD-19. Everything 19 is stuff that will only ever be written the one time so I give it the one time overkill pass to compress as much as possible. All the LZ4 stuff is read/write data. Both open LZ4 and ZSTD open files extremely fast so I consider them to be the best choices for read/write and write once data.

[skeevy420]

It's going to be real fun to see the BTRFS reactions when OpenZFS lands the patchset for adding disks to a RAID-5/6 later this year.

No only is RAID-5/6 terminally broken on BTRFS, but expansion has been probably the only real feature BTRFS has had over ZFS.

At this rate somebody'll evolve RedoxFS into the next ZFS replacement and merge that into the kernel before BTRFS's RAID is usable. In other words: the end of the universe.

If you're crazy like me you can do ZFS expansion now without the loss of space the upcoming method will have.