zfs: zpool-trim.timer enabled without zfs configured

Inbox
1

Running -unstable as of today (18.10.2019)

  $ nixos-version --hash
  1c40ee6fc44f7eb474c69ea070a43247a1a2c83c

which should include

  nixos/zfs: only enable trim if zfs is enabled · NixOS/nixpkgs@a412d90 · GitHub
  Author: Jörg Thalheim <joerg@thalheim.io>

    nixos/zfs: only enable trim if zfs is enabled

    Also don't fail the service if there are no pools yet.
    This might happen on installation ISOs.

My setup uses ext4 on a single disk only, no ZFS configured in any way,
and yet, the zpool-trim.timer is activated:

  nix-repl> config.services.zfs.trim
  { enable = true; interval = "weekly"; }

  $ systemctl status zpool-trim
  ● zpool-trim.service - ZFS pools trim
     Loaded: loaded (/nix/store/s79lxbk1cqwsdspds0vdxdkqnacn33pq-unit-zpool-trim.service/zpool-trim.service; linked; vendor preset: enabled)
     Active: inactive (dead)

1 Like
2

What is the value of config.boot.initrd.supportedFilesystems and config.boot.supportedFilesystems?
https://github.com/NixOS/nixpkgs/commit/9a894676068434ad953fc70091885ac12093fd31#diff-147de6a606fec1e25a6aa121f384ab25R17

1 Like
3

As expected:

nix-repl> config.boot.initrd.supportedFilesystems                        
[ "ext4" ]

nix-repl> config.boot.supportedFilesystems        
[ "ext4" ]
1 Like
4

Sorry, no idea, why it would be enabled in that case.

The condition looks straight forward to me: nixos/zfs: simplify logic for scrub/autosnapshot service · NixOS/nixpkgs@9a89467 · GitHub

1 Like
5

All of this is under zfs.nix:320 (mkIf enableZfs { which should
evaluate to false in my case.

In zfs.nix:268 services.zfs.trim = { enable defaults to true, could
that somehow cause config.systemd.timers.zpool-trim.enable default to
true as well irregardless of the check you linked above?

1 Like
6

If you look at the actual pull requests for your nixos-version --hash and the commit that fixes this issue, you’ll see that your nixos version was merged 5 days ago, and the fix was only merged 4 days ago. I bet if you look at your local nixpkgs tree you’ll find the fix is not applied. Looks like it simply hasn’t gotten to the nixos-unstable channel yet.

1 Like
7

If you look at the actual pull requests for your nixos-version --hash and the commit that fixes this issue, you’ll see that your nixos version was merged 5 days ago, and the fix was only merged 4 days ago. I bet if you look at your local nixpkgs tree you’ll find the fix is not applied. Looks like it simply hasn’t gotten to the nixos-unstable channel yet.
I did not even know about `nixos-version --hash’ until earlier this day
and am still lost between pull requests, commit hashes, build numbers
and what not.

I did look at the date of my build’s commit id

$ nixos-version --hash
1c40ee6fc44f7eb474c69ea070a43247a1a2c83c
$ git show 1c40ee6fc44f7eb474c69ea070a43247a1a2c83c
commit 1c40ee6fc44f7eb474c69ea070a43247a1a2c83c (origin/nixos-unstable)
Merge: 33366cce147 6d37f07301c
Author: Renaud <c0bw3b@users.noreply.github.com>
1 Like
8

The dates of the commits are not the dates they were merged to master. The commit date is the date they were originally authored, before the PR even went up.

1 Like