Hacker News Reader

Comment by Philipp__ | Hacker News Reader

I was kinda bummed when Apple announced that they are going with APFS instead of ZFS. I think ZFS is one of the biggest engineering feats in last decade or so of software engineering. It still needs wider adoption.

View on HN

The moment Oracle bought ZFS and Java Apple ditched all plans for both.

It would really be nice if there were a way to shrink vdevs on a live filesystem. That's the one feature that ZFS can't do at all that other filesystems can do equivalents of.

if you count XFS as “that other fs”, then no, it can't

Other FSs can shrink partitions without losing data; ZFS can't. The fact that XFS can't doesn't make my statement false.

Other filesystems will lose your data or write corrupted data

APFS and BtrFS at least won't.

APFS doesn't checksum the data. You've been deceived.

BTRFS still cannot be trusted for various reasons. It was deprecated as of RHEL 7.4

What reasons? openSUSE is defaulting to btrfs. snapper is really sweet.

Because RHEL kernels are very old and the maintenance burden of backporting btrfs changes is too great (and fragile).

That sounds like a problem with RHEL, not a problem with btrfs

For the end user it's a problem with the ecosystem. Red Hat needs to keep the kernel patched for a very long time and some pieces move way too fast.

Right, it's not a btrfs problem other than btrfs is moving too quickly and RHEL's kernel stands still (by design).

Being deprecated in RHEL means nothing; Red Hat didn't have any btrfs people anyway. They have all the xfs people, so that's what they focus on.

As long as you don't use Btrfs's RAID 5/6 features. I happened to be more lucky and my filesystem only locked up read-only on me, and I had to transfer everything off.

ZFS would be terrible for most of Apple's use cases. It is definitely designed around the assumption of fairly active sysadmins a la Solaris in 2005.

It's very good at what it does within that assumption, of course. But do you think behaviours like "you filled up too much of your disk, performance is crippled unless you wipe and rebuild" is "Just Works"?

How do you think they could achieve wider adoption?

The problem is the license, which ZFS on Linux covers a bit here: https://github.com/zfsonlinux/zfs/wiki/FAQ#licensing

You can see some of the fun hoops you have to go through to get ZFS as your root filesystem here: https://github.com/zfsonlinux/zfs/wiki/Ubuntu-16.04-Root-on-...

For now I just have 4 disks in a ZFS-raid for storage, and then I have installed my OS on a separate SSD.

The license is only a problem for gpl. Note that FreeBSD uses zfs and has for quite some time.

Yes - that is true, and it seems like ZFS usage is much higher there because of that.

Ubuntu has it built in and ready to go. But not for the root drive (that way lies madness).

It's quite excellent for the root drive, you just have to install via debootstrap. I personally do this on all my 1/2 dozen boxes (Straight Debian usually, but some Ubuntu). I've also written up how to build an AWS AMI this way. Good stuff, It's only going to get easier.

> I've also written up how to build an AWS AMI this way

If you've written it up in public, any chance of a link?

from their submission history: https://scotte.org/2016/12/ZFS-root-filesystem-on-AWS

It's not difficult really (assuming one can/is willing to RTFM), just a little more involved and time-consuming to get set up. I've used ZFS on / on Ubuntu a handful of times and all of the machines I use on a daily basis (a high-end workstation and a pair of laptops, all running Arch Linux) all use ZFS exclusively.

I have one (centos) machine with zfs on /. Looking back, it was a mistake - I always dread, when I see grub update in the yum update list, what will break this time.

And of course, after each kernel update, link your /dev/by-id/... devices into /dev and rerun grub2-mkconfig by hand. Otherwise, you won't boot the new kernel you just updated.

If this machine weren't a pet, it would be wiped clean and reinstalled with xfs /.

Wow. That sounds like something isn't configured quite right. Or perhaps ZFS just isn't as well "integrated" on CentOS.

All of my Linux machines with ZFS are running Arch Linux (as well as a few servers running FreeBSD) and I don't have to do anything special.

For example, I'll update them every few days (or whenever I don't mind having to "re-open" all my applications, tabs, etc.) and I just run "pacaur -Syyu", have it update everything, and reboot when it's done. It starts back up, I enter in my FDE passphrase, and it boots right up.

It is actually a known issue between ZoL and GRUB:

https://github.com/zfsonlinux/grub/issues/5

zpool status will show only basename component of the device name and grub will look for it in /dev only. As I created the pool with ata-* device names, which are constant per device, it will of course fail, because they are in the /dev/by-id/ and grub is not looking for them there.

Next time there is a kernel update, I' going to try the env variable mentioned in the august 2017 comment. Hopefully it will work right.

ZFS and CentOS are not a good combination, in my experience. The Red Hat/Oracle feud doesn't give RH much incentive to be ZFS-friendly, and the interaction between DKMS and weak-modules is a fiasco.

ZFS woes, and Red Hat's penchant for yanking hardware support (like a PERC/4e RAID controller I encountered this spring), have brought me to the point that the only new CentOS installations I'll make will be KVM guests.

The last straw for me was the 1708 release, when the ZFS modules failed to build, leaving my home NAS stuck on the old kernel. Out went CentOS, in went Ubuntu Server. No regrets.

In my case, Ubuntu makes PITA running stuff I want to run (especially FreeIPA/sssd/gssapi integration). On the other hand, I'm using kmod repo for ZoL, not DKMS, because I wanted to avoid having a compiler and dev packages on the server in the first place. CentOS/RHEL have kernel ABIs, why not use them.

That's odd. I've been using it on Ubuntu as the rootfs for over 18 months now and have been through 16.04/16.10/17.04/17.10 upgrades and numerous kernel upgrades and it's worked flawlessly every time.

And that's the thing. I used SmartOS for a while and while there's nothing wrong with a ZFS root, per se, you're still at the mercy of boot loaders and whatever Amazon will or will not let you do.

So I've taken to having ext4 or whatever as the boot drive and a zpool for anything I care about :)

Not really, I use it on Arch as my root drive https://ramsdenj.com/2016/06/23/arch-linux-on-zfs-part-2-ins... and never have a problem. It's been useful multiple times for informing me that I have a problem disc, and being able to go back in time and look at how things have changed on my system with snapshots is of great benefit. Being able to rollback, clone filesystems and send them around is great too.

With archzfs I get binary upgrades with every kernel, and I've never had a problem at boot after a kernel update.

The problem back when was that Sun wouldn't indemnify Apple against third party patent claims. Now that Solaris is dead it is unclear what Oracle's intentions are, but in any case, surely Apple would have similar desires.

It's happening via NAS-type devices - a lot of those use ZFS behind the scenes. Once people get used to that kind of functionality, they'll ask why their computer doesn't do that on its local drive, maybe.

Reply on news.ycombinator.com