[Dont Merge] nixos-iso: Add zfs / btrfs to supportedFilesystems

[wkennington]

Does this seem reasonable to everyone? My only worry is that zfs sometimes falls behind in supporting newer kernels which would cause the iso build to fail. It would be nice to be able to create zfs root installs and access zfs pools from the iso though.

[jgeerds]

I'm running multiple btrfs formatted NixOS machines without problems
(grub and gummiboot, lzo-compressed /boot and all this crazy stuff :))

[wkennington]

Oh yeah, as am I. I'm not worried about adding btrfs, really just zfs support since it isn't a mainlined package and fails to build against the kernel from time to time.

[wmertens]

So basically, btrfs can be supported but zfs can't.

[wkennington]

@wizeman Do you have faith in zfs support for this?

I really don't foresee this being an issue with the stable kernel, just the latest kernel.

[wizeman]

@wkennington In short, I think it would be fine (and a good idea) to add built-in ZFS support to the ISO.

Here's the long version of what I think about this:

If I'm not mistaken, it took around 9.5 months to go from zfs-0.6.2 to zfs-0.6.3, and in the mean time it fell behind quite a bit: AFAICS 0.6.2 supported only kernel 3.11, while by the time 0.6.3 was finally released the newest kernel was already 3.15 (but I don't know which kernel NixOS was using as the stable one during this whole time).

First of all, it's possible that such a long release time could have been an outlier.

But more importantly, this was not such a big problem for the following reasons:

Usually, the problem with newer kernels is that sometimes kernel APIs change, and ZFS fails to build against the newer APIs. But usually the fix is trivial (or almost trivial), because most API changes are insignificant or relatively simple to adapt to. In fact, usually most new kernels were supported in the zfs git repositories within a relatively short time period (usually within a week or so, sometimes even before the kernels were even released).

So what I did during this time was to keep backporting these patches to the stable (0.6.2) spl/zfs derivations, so that they kept building with newer kernels in NixOS.

Another option is that if it's not easy to backport these patches, we can switch to the splGit/zfsGit derivations, which can be built off any specific git commit that we want. This might sound dangerous but in practice it has worked quite well: I ran my systems on specific git commits for months, and it was quite stable during the whole time (in fact, it was even more stable than the stable release).

I think there was only one serious bug committed to the git repositories in-between the 0.6.2 and 0.6.3 releases, and IIRC it was discovered and fixed within a few days, so even if we were using splGit/zfsGit, the chances that we would have used broken code would have been quite small.

Anyway, if this ever becomes a substantial problem, it would be quite easy to revert support for ZFS in the ISO, so I think this is not a problem at all...

[wkennington]

I appreciate the response and I'm going to move ahead with this.

[domenkozar]

@wkennington this breaks rebuildCD test: http://hydra.nixos.org/build/16496744

[wizeman]

@iElectric This is a bug in upstream ZFS (openzfs/zfs#2368) that can be very crudely worked around by making the zpool-import.service ignore failures.

However, this is not a good solution, and I've been working on and testing an extensive fix for this (along with other issues) in the past couple of weeks. Either today or tomorrow (as time allows), I will submit a PR with the proper fixes.

[wizeman]

@iElectric I have submitted PR #4807 which should solve that issue

[Rudd-O]

The bug in ZFS was fixed. Check the upstream bug. openzfs/zfs#2368 (comment)