Btrfs Restoring Support For Swap Files With Linux 4.21

[moltonel]

I still like being able to compress /etc and document directories with gzip9; lz4 for binary directories, I can grow and shrink swap as necessary (never had to, but I can), I can have system wide snapshots, file system based encryption (no encryption layers, yay), I don't have to worry about disk schedulers because the answer is always NOOP with ZFS, there are file system based mirrors and raid options, it has logging and cache drive support to increase performance (Windows/NTFS somewhat does that too)...IMHO, the benefits of ZFS outweigh the negative aspects. Besides, ZFS on Linux should only get better and gain more performance as they creep towards the 1.0 release.

Seems like the only regression you'd get by moving to BTRFS is the lack of integrated encryption and mature raid-5 ? Per-file/subvol compression params is available (and you would gain zstd), disk scheduler is more related to your hardware than your filesystem (and choosing requires much less knowledge than installing an out of tree filesystem), btrfs can easily take advantage of an SSD/HDD mix.

ZFS had a head-start over BTRFS, but development has slowed considerably since Oracle. BTRFS has caught up on nearly all features, overtaken on some others (I would really miss send/receive if I moved to ZFS), is improving faster (raid 5/6 will soon be there, encryption is on the roadmap) and gets more testing. BTRFS is not flawless, but it is IMHO a surer bet than ZFS for my personal and professional data.

[darkbasic]

Then ZFS doesn't let you disable CoW per file, like BTRFS does. Instead it has zvols, which are a poor man's substitute for non-cow files.

ZVOLs are *NOT* poor man's substitute for non-cow files: on the contrary they are *COW* block devices.

[darkbasic]

ZFS had a head-start over BTRFS, but development has slowed considerably since Oracle.

Its development is still way faster than btrfs'.

[skeevy420]

Seems like the only regression you'd get by moving to BTRFS is the lack of integrated encryption and mature raid-5 ? Per-file/subvol compression params is available (and you would gain zstd), disk scheduler is more related to your hardware than your filesystem (and choosing requires much less knowledge than installing an out of tree filesystem), btrfs can easily take advantage of an SSD/HDD mix.

ZFS had a head-start over BTRFS, but development has slowed considerably since Oracle. BTRFS has caught up on nearly all features, overtaken on some others (I would really miss send/receive if I moved to ZFS), is improving faster (raid 5/6 will soon be there, encryption is on the roadmap) and gets more testing. BTRFS is not flawless, but it is IMHO a surer bet than ZFS for my personal and professional data.

ZFS has send/receive. I don't know if it's the same as what BTRFS has, but send/recv is the standard way to backup and send snapshots to a file or another system. ZFS also supports ZSTD too. The ZFS wiki recommends using NOOP since it's a simple io scheduler and ZFS manages disk scheduling on its own. The necessary disk scheduler to use is a combination of file system, hardware, and use case (like a database drive and a random crap filled /home drive needing different settings for optimal performance).

[skeevy420]

Me neither.

I did have some Ubuntu-based distros blow up like that and leave a text-only install so I can't say it's impossible

Antergos is indeed interesting and I'm keeping an eye on it to see if it's eventually worth to jump ship from Tumbleweed. It's already much better than it was a year ago as far as integration and user-friendlyness.

I've had the same experiences with Ubuntu/Debian too. Not saying that scenario is impossible, just very improbable.

I've been using Antergos for around three years now. If you like Arch but dislike the ground up install process or you like Manjaro but dislike the Manjaro hand holding, Antergos makes a great solution.

Also, Antergos is one of the few Linux distributions that actually has a ZFS on Root install option -- 3 years in and it's still running great (outside of that KDE unmount taking forever post I described the other day). The only downside is the Antergos ZFS installer isn't very flexible and you can't do extremely intricate pool setups unless you install to one disk, tweak out a 2nd disk, send/recv from one disk to the other, and update Grub/set rootfs/bootfs accordingly (that describes every ZoL distribution installer so that annoyance isn't limited to just Antergos).

[starshipeleven]

Not true at all, they fixed it two years ago.

It's "fixed" in the same way ZFS fixed it, by adding the ability to use a journaling device.

[starshipeleven]

Also, Antergos is one of the few Linux distributions that actually has a ZFS on Root install option -- 3 years in and it's still running great (outside of that KDE unmount taking forever post I described the other day). The only downside is the Antergos ZFS installer isn't very flexible and you can't do extremely intricate pool setups unless you install to one disk, tweak out a 2nd disk, send/recv from one disk to the other, and update Grub/set rootfs/bootfs accordingly (that describes every ZoL distribution installer so that annoyance isn't limited to just Antergos).

Yeah that's the thing that is making me keep an eye on it.

[waxhead]

Not true at all, they fixed it two years ago.

They did? I was under the impression that closing the write hole on all but raid0 requires a separate journal device, which means that by default it is not closed. I would appreciate if you can share a link to this! Thanks!

[jpg44]

Soon the default setting of openSUSE and SUSE should change and by default / home should be a subvolume.
I remain of the opinion that if you do not care about the snapshots or other things of Btrfs you can easily stay with Ext4, there are no reasons to change, but if like me you need to have a system that can be restored in a few minutes in case of problems, then Btrfs is the right choice, because at the moment it is the only one that allows this. Then we can be fans of this or that, but this is reality.
The only thing that I would like to point out is that it has been using Btrfs for 2 years both for / and for the /home and I have never had any problem of data corruption or anything like that, so for me Btrfs is reliable.

i though this had already happened some time ago with Suse subvolumes. Btrfs is a very reliable filesystem, raid 5/6 is coming along well and should be production ready very soon. Btrfs is ready to replace Ext4 completely today., Ext4 never had Raid 5/6 in the first place

[jacob]

ZVOLs are *NOT* poor man's substitute for non-cow files: on the contrary they are *COW* block devices.

Correct me if I'm wrong but I believe that only ZVOL metadata use CoW, the stored data themselves are overwritten, which is actually the very difference between a ZVOL and a normal ZFS file. There can still be on-demand data CoW, such as when a ZVOL is snapshotted. In effect these are exactly the same features as non-CoW files in BTRFS, without the ease of use.

For completeness' sake, in BTRFS it is theoretically possible to disable metadata CoW as well but I really don't see any sensible use case for that.