nixos/zfs: Improve the ZFS boot process
It turns out that the upstream systemd services that import ZFS pools contain
serious bugs. The first major problem is that importing pools fails if there
are no pools to import. The second major problem is that if a pool ends up in
/etc/zfs/zpool.cache but it disappears from the system (e.g. if you
reboot but during the reboot you unplug your ZFS-formatted USB pen drive),
then the import service will always fail and it will be impossible to get rid
of the pool from the cache (unless you manually delete the cache).
Also, the upstream service would always import all available ZFS pools every
boot, which may not be what is desired in some cases.
This commit will solve these problems in the following ways:
1. Ignore /etc/zfs/zpool.cache. This seems to be a major source of
issues, and also does not play well with NixOS's philosophy of
reproducible configurations. Instead, on every boot NixOS will try to import
the set of pools that are specified in its configuration. This is also the
direction that upstream is moving towards.
2. Instead of trying to import all ZFS pools, only import those that are
actually necessary. NixOS will automatically determine these from the
config.fileSystems.* option. Also, the user can import any additional
pools every boot by adding them to the config.boot.zfs.extraPools
option, but this is only necessary if their filesystems are not
specified in config.fileSystems.*.
3. Added options to configure if ZFS should force-import ZFS pools. This may
currently be necessary, especially if your pools have not been correctly
imported with a proper host id configuration (which is probably true for 99% of
current NixOS ZFS users). Once host id configuration becomes mandatory when
using ZFS in NixOS and we are sure that most users have updated their
configurations and rebooted at least once, we should disable force-import by
default. Probably, this shouldn't be done before the next stable release.
WARNING: This commit may change the order in which your non-ZFS vs ZFS
filesystems are mounted. To avoid this problem (now or in the future)
it is recommended that you set the 'mountpoint' property of your ZFS
filesystems to 'legacy', and that you manage them using
config.fileSystems, just like any other non-ZFS filesystem is usually
managed in NixOS.
2014-10-22 19:17:21 +02:00
|
|
|
{ config, lib, pkgs, utils, ... }:
|
2012-12-04 20:57:59 +01:00
|
|
|
#
|
|
|
|
# todo:
|
|
|
|
# - crontab for scrubs, etc
|
|
|
|
# - zfs tunables
|
2012-12-04 19:17:54 +01:00
|
|
|
|
nixos/zfs: Improve the ZFS boot process
It turns out that the upstream systemd services that import ZFS pools contain
serious bugs. The first major problem is that importing pools fails if there
are no pools to import. The second major problem is that if a pool ends up in
/etc/zfs/zpool.cache but it disappears from the system (e.g. if you
reboot but during the reboot you unplug your ZFS-formatted USB pen drive),
then the import service will always fail and it will be impossible to get rid
of the pool from the cache (unless you manually delete the cache).
Also, the upstream service would always import all available ZFS pools every
boot, which may not be what is desired in some cases.
This commit will solve these problems in the following ways:
1. Ignore /etc/zfs/zpool.cache. This seems to be a major source of
issues, and also does not play well with NixOS's philosophy of
reproducible configurations. Instead, on every boot NixOS will try to import
the set of pools that are specified in its configuration. This is also the
direction that upstream is moving towards.
2. Instead of trying to import all ZFS pools, only import those that are
actually necessary. NixOS will automatically determine these from the
config.fileSystems.* option. Also, the user can import any additional
pools every boot by adding them to the config.boot.zfs.extraPools
option, but this is only necessary if their filesystems are not
specified in config.fileSystems.*.
3. Added options to configure if ZFS should force-import ZFS pools. This may
currently be necessary, especially if your pools have not been correctly
imported with a proper host id configuration (which is probably true for 99% of
current NixOS ZFS users). Once host id configuration becomes mandatory when
using ZFS in NixOS and we are sure that most users have updated their
configurations and rebooted at least once, we should disable force-import by
default. Probably, this shouldn't be done before the next stable release.
WARNING: This commit may change the order in which your non-ZFS vs ZFS
filesystems are mounted. To avoid this problem (now or in the future)
it is recommended that you set the 'mountpoint' property of your ZFS
filesystems to 'legacy', and that you manage them using
config.fileSystems, just like any other non-ZFS filesystem is usually
managed in NixOS.
2014-10-22 19:17:21 +02:00
|
|
|
with utils;
|
2014-04-14 16:26:48 +02:00
|
|
|
with lib;
|
2012-12-04 19:17:54 +01:00
|
|
|
|
|
|
|
let
|
|
|
|
|
2012-12-07 00:12:10 +01:00
|
|
|
cfgSpl = config.boot.spl;
|
2014-03-22 18:27:23 +01:00
|
|
|
cfgZfs = config.boot.zfs;
|
2014-01-22 01:11:51 +01:00
|
|
|
cfgSnapshots = config.services.zfs.autoSnapshot;
|
|
|
|
|
2012-12-04 19:17:54 +01:00
|
|
|
inInitrd = any (fs: fs == "zfs") config.boot.initrd.supportedFilesystems;
|
2012-12-04 20:57:59 +01:00
|
|
|
inSystem = any (fs: fs == "zfs") config.boot.supportedFilesystems;
|
2014-01-22 01:11:51 +01:00
|
|
|
|
|
|
|
enableAutoSnapshots = cfgSnapshots.enable;
|
|
|
|
enableZfs = inInitrd || inSystem || enableAutoSnapshots;
|
|
|
|
|
2012-12-04 19:17:54 +01:00
|
|
|
kernel = config.boot.kernelPackages;
|
|
|
|
|
2015-09-29 14:26:20 +02:00
|
|
|
splKernelPkg = kernel.spl;
|
|
|
|
zfsKernelPkg = kernel.zfs;
|
|
|
|
zfsUserPkg = pkgs.zfs;
|
2014-03-22 18:27:23 +01:00
|
|
|
|
2014-01-22 01:11:51 +01:00
|
|
|
autosnapPkg = pkgs.zfstools.override {
|
2015-02-08 00:07:30 +01:00
|
|
|
zfs = zfsUserPkg;
|
2014-01-22 01:11:51 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
zfsAutoSnap = "${autosnapPkg}/bin/zfs-auto-snapshot";
|
|
|
|
|
nixos/zfs: Improve the ZFS boot process
It turns out that the upstream systemd services that import ZFS pools contain
serious bugs. The first major problem is that importing pools fails if there
are no pools to import. The second major problem is that if a pool ends up in
/etc/zfs/zpool.cache but it disappears from the system (e.g. if you
reboot but during the reboot you unplug your ZFS-formatted USB pen drive),
then the import service will always fail and it will be impossible to get rid
of the pool from the cache (unless you manually delete the cache).
Also, the upstream service would always import all available ZFS pools every
boot, which may not be what is desired in some cases.
This commit will solve these problems in the following ways:
1. Ignore /etc/zfs/zpool.cache. This seems to be a major source of
issues, and also does not play well with NixOS's philosophy of
reproducible configurations. Instead, on every boot NixOS will try to import
the set of pools that are specified in its configuration. This is also the
direction that upstream is moving towards.
2. Instead of trying to import all ZFS pools, only import those that are
actually necessary. NixOS will automatically determine these from the
config.fileSystems.* option. Also, the user can import any additional
pools every boot by adding them to the config.boot.zfs.extraPools
option, but this is only necessary if their filesystems are not
specified in config.fileSystems.*.
3. Added options to configure if ZFS should force-import ZFS pools. This may
currently be necessary, especially if your pools have not been correctly
imported with a proper host id configuration (which is probably true for 99% of
current NixOS ZFS users). Once host id configuration becomes mandatory when
using ZFS in NixOS and we are sure that most users have updated their
configurations and rebooted at least once, we should disable force-import by
default. Probably, this shouldn't be done before the next stable release.
WARNING: This commit may change the order in which your non-ZFS vs ZFS
filesystems are mounted. To avoid this problem (now or in the future)
it is recommended that you set the 'mountpoint' property of your ZFS
filesystems to 'legacy', and that you manage them using
config.fileSystems, just like any other non-ZFS filesystem is usually
managed in NixOS.
2014-10-22 19:17:21 +02:00
|
|
|
datasetToPool = x: elemAt (splitString "/" x) 0;
|
|
|
|
|
|
|
|
fsToPool = fs: datasetToPool fs.device;
|
|
|
|
|
|
|
|
zfsFilesystems = filter (x: x.fsType == "zfs") (attrValues config.fileSystems);
|
|
|
|
|
|
|
|
isRoot = fs: fs.neededForBoot || elem fs.mountPoint [ "/" "/nix" "/nix/store" "/var" "/var/log" "/var/lib" "/etc" ];
|
|
|
|
|
|
|
|
allPools = unique ((map fsToPool zfsFilesystems) ++ cfgZfs.extraPools);
|
|
|
|
|
|
|
|
rootPools = unique (map fsToPool (filter isRoot zfsFilesystems));
|
|
|
|
|
|
|
|
dataPools = unique (filter (pool: !(elem pool rootPools)) allPools);
|
|
|
|
|
2012-12-04 19:17:54 +01:00
|
|
|
in
|
|
|
|
|
|
|
|
{
|
|
|
|
|
2012-12-04 20:57:59 +01:00
|
|
|
###### interface
|
2014-01-22 01:11:51 +01:00
|
|
|
|
|
|
|
options = {
|
nixos/zfs: Improve the ZFS boot process
It turns out that the upstream systemd services that import ZFS pools contain
serious bugs. The first major problem is that importing pools fails if there
are no pools to import. The second major problem is that if a pool ends up in
/etc/zfs/zpool.cache but it disappears from the system (e.g. if you
reboot but during the reboot you unplug your ZFS-formatted USB pen drive),
then the import service will always fail and it will be impossible to get rid
of the pool from the cache (unless you manually delete the cache).
Also, the upstream service would always import all available ZFS pools every
boot, which may not be what is desired in some cases.
This commit will solve these problems in the following ways:
1. Ignore /etc/zfs/zpool.cache. This seems to be a major source of
issues, and also does not play well with NixOS's philosophy of
reproducible configurations. Instead, on every boot NixOS will try to import
the set of pools that are specified in its configuration. This is also the
direction that upstream is moving towards.
2. Instead of trying to import all ZFS pools, only import those that are
actually necessary. NixOS will automatically determine these from the
config.fileSystems.* option. Also, the user can import any additional
pools every boot by adding them to the config.boot.zfs.extraPools
option, but this is only necessary if their filesystems are not
specified in config.fileSystems.*.
3. Added options to configure if ZFS should force-import ZFS pools. This may
currently be necessary, especially if your pools have not been correctly
imported with a proper host id configuration (which is probably true for 99% of
current NixOS ZFS users). Once host id configuration becomes mandatory when
using ZFS in NixOS and we are sure that most users have updated their
configurations and rebooted at least once, we should disable force-import by
default. Probably, this shouldn't be done before the next stable release.
WARNING: This commit may change the order in which your non-ZFS vs ZFS
filesystems are mounted. To avoid this problem (now or in the future)
it is recommended that you set the 'mountpoint' property of your ZFS
filesystems to 'legacy', and that you manage them using
config.fileSystems, just like any other non-ZFS filesystem is usually
managed in NixOS.
2014-10-22 19:17:21 +02:00
|
|
|
boot.zfs = {
|
|
|
|
|
|
|
|
extraPools = mkOption {
|
|
|
|
type = types.listOf types.str;
|
|
|
|
default = [];
|
|
|
|
example = [ "tank" "data" ];
|
|
|
|
description = ''
|
|
|
|
Name or GUID of extra ZFS pools that you wish to import during boot.
|
|
|
|
|
|
|
|
Usually this is not necessary. Instead, you should set the mountpoint property
|
|
|
|
of ZFS filesystems to <literal>legacy</literal> and add the ZFS filesystems to
|
|
|
|
NixOS's <option>fileSystems</option> option, which makes NixOS automatically
|
|
|
|
import the associated pool.
|
|
|
|
|
|
|
|
However, in some cases (e.g. if you have many filesystems) it may be preferable
|
|
|
|
to exclusively use ZFS commands to manage filesystems. If so, since NixOS/systemd
|
|
|
|
will not be managing those filesystems, you will need to specify the ZFS pool here
|
|
|
|
so that NixOS automatically imports it on every boot.
|
|
|
|
'';
|
|
|
|
};
|
|
|
|
|
|
|
|
forceImportRoot = mkOption {
|
|
|
|
type = types.bool;
|
|
|
|
default = true;
|
|
|
|
example = false;
|
|
|
|
description = ''
|
|
|
|
Forcibly import the ZFS root pool(s) during early boot.
|
|
|
|
|
|
|
|
This is enabled by default for backwards compatibility purposes, but it is highly
|
|
|
|
recommended to disable this option, as it bypasses some of the safeguards ZFS uses
|
|
|
|
to protect your ZFS pools.
|
|
|
|
|
|
|
|
If you set this option to <literal>false</literal> and NixOS subsequently fails to
|
|
|
|
boot because it cannot import the root pool, you should boot with the
|
|
|
|
<literal>zfs_force=1</literal> option as a kernel parameter (e.g. by manually
|
|
|
|
editing the kernel params in grub during boot). You should only need to do this
|
|
|
|
once.
|
|
|
|
'';
|
|
|
|
};
|
|
|
|
|
|
|
|
forceImportAll = mkOption {
|
|
|
|
type = types.bool;
|
|
|
|
default = true;
|
|
|
|
example = false;
|
|
|
|
description = ''
|
|
|
|
Forcibly import all ZFS pool(s).
|
|
|
|
|
|
|
|
This is enabled by default for backwards compatibility purposes, but it is highly
|
|
|
|
recommended to disable this option, as it bypasses some of the safeguards ZFS uses
|
|
|
|
to protect your ZFS pools.
|
|
|
|
|
|
|
|
If you set this option to <literal>false</literal> and NixOS subsequently fails to
|
|
|
|
import your non-root ZFS pool(s), you should manually import each pool with
|
|
|
|
"zpool import -f <pool-name>", and then reboot. You should only need to do
|
|
|
|
this once.
|
|
|
|
'';
|
|
|
|
};
|
2014-03-22 18:27:23 +01:00
|
|
|
};
|
|
|
|
|
2014-01-22 01:11:51 +01:00
|
|
|
services.zfs.autoSnapshot = {
|
|
|
|
enable = mkOption {
|
|
|
|
default = false;
|
|
|
|
type = types.bool;
|
|
|
|
description = ''
|
|
|
|
Enable the (OpenSolaris-compatible) ZFS auto-snapshotting service.
|
|
|
|
Note that you must set the <literal>com.sun:auto-snapshot</literal>
|
|
|
|
property to <literal>true</literal> on all datasets which you wish
|
|
|
|
to auto-snapshot.
|
2012-12-04 19:17:54 +01:00
|
|
|
|
2014-01-22 01:11:51 +01:00
|
|
|
You can override a child dataset to use, or not use auto-snapshotting
|
|
|
|
by setting its flag with the given interval:
|
|
|
|
<literal>zfs set com.sun:auto-snapshot:weekly=false DATASET</literal>
|
|
|
|
'';
|
|
|
|
};
|
2012-12-04 19:17:54 +01:00
|
|
|
|
2014-01-22 01:11:51 +01:00
|
|
|
frequent = mkOption {
|
|
|
|
default = 4;
|
|
|
|
type = types.int;
|
|
|
|
description = ''
|
|
|
|
Number of frequent (15-minute) auto-snapshots that you wish to keep.
|
|
|
|
'';
|
|
|
|
};
|
|
|
|
|
|
|
|
hourly = mkOption {
|
|
|
|
default = 24;
|
|
|
|
type = types.int;
|
|
|
|
description = ''
|
|
|
|
Number of hourly auto-snapshots that you wish to keep.
|
|
|
|
'';
|
|
|
|
};
|
|
|
|
|
|
|
|
daily = mkOption {
|
|
|
|
default = 7;
|
|
|
|
type = types.int;
|
|
|
|
description = ''
|
|
|
|
Number of daily auto-snapshots that you wish to keep.
|
|
|
|
'';
|
|
|
|
};
|
2012-12-04 19:17:54 +01:00
|
|
|
|
2014-01-22 01:11:51 +01:00
|
|
|
weekly = mkOption {
|
|
|
|
default = 4;
|
|
|
|
type = types.int;
|
|
|
|
description = ''
|
|
|
|
Number of weekly auto-snapshots that you wish to keep.
|
2012-12-04 20:57:59 +01:00
|
|
|
'';
|
2014-01-22 01:11:51 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
monthly = mkOption {
|
|
|
|
default = 12;
|
|
|
|
type = types.int;
|
|
|
|
description = ''
|
|
|
|
Number of monthly auto-snapshots that you wish to keep.
|
2012-12-04 20:57:59 +01:00
|
|
|
'';
|
2014-01-22 01:11:51 +01:00
|
|
|
};
|
2012-12-04 20:57:59 +01:00
|
|
|
};
|
2014-01-22 01:11:51 +01:00
|
|
|
};
|
2012-12-04 19:17:54 +01:00
|
|
|
|
2014-01-22 01:11:51 +01:00
|
|
|
###### implementation
|
|
|
|
|
|
|
|
config = mkMerge [
|
|
|
|
(mkIf enableZfs {
|
nixos/zfs: Improve the ZFS boot process
It turns out that the upstream systemd services that import ZFS pools contain
serious bugs. The first major problem is that importing pools fails if there
are no pools to import. The second major problem is that if a pool ends up in
/etc/zfs/zpool.cache but it disappears from the system (e.g. if you
reboot but during the reboot you unplug your ZFS-formatted USB pen drive),
then the import service will always fail and it will be impossible to get rid
of the pool from the cache (unless you manually delete the cache).
Also, the upstream service would always import all available ZFS pools every
boot, which may not be what is desired in some cases.
This commit will solve these problems in the following ways:
1. Ignore /etc/zfs/zpool.cache. This seems to be a major source of
issues, and also does not play well with NixOS's philosophy of
reproducible configurations. Instead, on every boot NixOS will try to import
the set of pools that are specified in its configuration. This is also the
direction that upstream is moving towards.
2. Instead of trying to import all ZFS pools, only import those that are
actually necessary. NixOS will automatically determine these from the
config.fileSystems.* option. Also, the user can import any additional
pools every boot by adding them to the config.boot.zfs.extraPools
option, but this is only necessary if their filesystems are not
specified in config.fileSystems.*.
3. Added options to configure if ZFS should force-import ZFS pools. This may
currently be necessary, especially if your pools have not been correctly
imported with a proper host id configuration (which is probably true for 99% of
current NixOS ZFS users). Once host id configuration becomes mandatory when
using ZFS in NixOS and we are sure that most users have updated their
configurations and rebooted at least once, we should disable force-import by
default. Probably, this shouldn't be done before the next stable release.
WARNING: This commit may change the order in which your non-ZFS vs ZFS
filesystems are mounted. To avoid this problem (now or in the future)
it is recommended that you set the 'mountpoint' property of your ZFS
filesystems to 'legacy', and that you manage them using
config.fileSystems, just like any other non-ZFS filesystem is usually
managed in NixOS.
2014-10-22 19:17:21 +02:00
|
|
|
assertions = [
|
nixos: Add system-wide option to set the hostid
The old boot.spl.hostid option was not working correctly due to an
upstream bug.
Instead, now we will create the /etc/hostid file so that all applications
(including the ZFS kernel modules, ZFS user-space applications and other
unrelated programs) pick-up the same system-wide host id. Note that glibc
(and by extension, the `hostid` program) also respect the host id configured in
/etc/hostid, if it exists.
The hostid option is now mandatory when using ZFS because otherwise, ZFS will
require you to force-import your ZFS pools if you want to use them, which is
undesirable because it disables some of the checks that ZFS does to make sure it
is safe to import a ZFS pool.
The /etc/hostid file must also exist when booting the initrd, before the SPL
kernel module is loaded, so that ZFS picks up the hostid correctly.
The complexity in creating the /etc/hostid file is due to having to
write the host ID as a 32-bit binary value, taking into account the
endianness of the machine, while using only shell commands and/or simple
utilities (to avoid exploding the size of the initrd).
2014-10-23 04:59:06 +02:00
|
|
|
{
|
|
|
|
assertion = config.networking.hostId != null;
|
|
|
|
message = "ZFS requires config.networking.hostId to be set";
|
|
|
|
}
|
nixos/zfs: Improve the ZFS boot process
It turns out that the upstream systemd services that import ZFS pools contain
serious bugs. The first major problem is that importing pools fails if there
are no pools to import. The second major problem is that if a pool ends up in
/etc/zfs/zpool.cache but it disappears from the system (e.g. if you
reboot but during the reboot you unplug your ZFS-formatted USB pen drive),
then the import service will always fail and it will be impossible to get rid
of the pool from the cache (unless you manually delete the cache).
Also, the upstream service would always import all available ZFS pools every
boot, which may not be what is desired in some cases.
This commit will solve these problems in the following ways:
1. Ignore /etc/zfs/zpool.cache. This seems to be a major source of
issues, and also does not play well with NixOS's philosophy of
reproducible configurations. Instead, on every boot NixOS will try to import
the set of pools that are specified in its configuration. This is also the
direction that upstream is moving towards.
2. Instead of trying to import all ZFS pools, only import those that are
actually necessary. NixOS will automatically determine these from the
config.fileSystems.* option. Also, the user can import any additional
pools every boot by adding them to the config.boot.zfs.extraPools
option, but this is only necessary if their filesystems are not
specified in config.fileSystems.*.
3. Added options to configure if ZFS should force-import ZFS pools. This may
currently be necessary, especially if your pools have not been correctly
imported with a proper host id configuration (which is probably true for 99% of
current NixOS ZFS users). Once host id configuration becomes mandatory when
using ZFS in NixOS and we are sure that most users have updated their
configurations and rebooted at least once, we should disable force-import by
default. Probably, this shouldn't be done before the next stable release.
WARNING: This commit may change the order in which your non-ZFS vs ZFS
filesystems are mounted. To avoid this problem (now or in the future)
it is recommended that you set the 'mountpoint' property of your ZFS
filesystems to 'legacy', and that you manage them using
config.fileSystems, just like any other non-ZFS filesystem is usually
managed in NixOS.
2014-10-22 19:17:21 +02:00
|
|
|
{
|
|
|
|
assertion = !cfgZfs.forceImportAll || cfgZfs.forceImportRoot;
|
|
|
|
message = "If you enable boot.zfs.forceImportAll, you must also enable boot.zfs.forceImportRoot";
|
|
|
|
}
|
|
|
|
];
|
|
|
|
|
2014-01-22 01:11:51 +01:00
|
|
|
boot = {
|
|
|
|
kernelModules = [ "spl" "zfs" ] ;
|
2015-02-08 00:07:30 +01:00
|
|
|
extraModulePackages = [ splKernelPkg zfsKernelPkg ];
|
2014-01-22 01:11:51 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
boot.initrd = mkIf inInitrd {
|
2014-08-31 18:18:13 +02:00
|
|
|
kernelModules = [ "spl" "zfs" ];
|
2014-01-22 01:11:51 +01:00
|
|
|
extraUtilsCommands =
|
|
|
|
''
|
2015-03-29 01:15:41 +01:00
|
|
|
copy_bin_and_libs ${zfsUserPkg}/sbin/zfs
|
|
|
|
copy_bin_and_libs ${zfsUserPkg}/sbin/zdb
|
|
|
|
copy_bin_and_libs ${zfsUserPkg}/sbin/zpool
|
|
|
|
'';
|
|
|
|
extraUtilsCommandsTest = mkIf inInitrd
|
|
|
|
''
|
|
|
|
$out/bin/zfs --help >/dev/null 2>&1
|
|
|
|
$out/bin/zpool --help >/dev/null 2>&1
|
2014-01-22 01:11:51 +01:00
|
|
|
'';
|
nixos/zfs: Improve the ZFS boot process
It turns out that the upstream systemd services that import ZFS pools contain
serious bugs. The first major problem is that importing pools fails if there
are no pools to import. The second major problem is that if a pool ends up in
/etc/zfs/zpool.cache but it disappears from the system (e.g. if you
reboot but during the reboot you unplug your ZFS-formatted USB pen drive),
then the import service will always fail and it will be impossible to get rid
of the pool from the cache (unless you manually delete the cache).
Also, the upstream service would always import all available ZFS pools every
boot, which may not be what is desired in some cases.
This commit will solve these problems in the following ways:
1. Ignore /etc/zfs/zpool.cache. This seems to be a major source of
issues, and also does not play well with NixOS's philosophy of
reproducible configurations. Instead, on every boot NixOS will try to import
the set of pools that are specified in its configuration. This is also the
direction that upstream is moving towards.
2. Instead of trying to import all ZFS pools, only import those that are
actually necessary. NixOS will automatically determine these from the
config.fileSystems.* option. Also, the user can import any additional
pools every boot by adding them to the config.boot.zfs.extraPools
option, but this is only necessary if their filesystems are not
specified in config.fileSystems.*.
3. Added options to configure if ZFS should force-import ZFS pools. This may
currently be necessary, especially if your pools have not been correctly
imported with a proper host id configuration (which is probably true for 99% of
current NixOS ZFS users). Once host id configuration becomes mandatory when
using ZFS in NixOS and we are sure that most users have updated their
configurations and rebooted at least once, we should disable force-import by
default. Probably, this shouldn't be done before the next stable release.
WARNING: This commit may change the order in which your non-ZFS vs ZFS
filesystems are mounted. To avoid this problem (now or in the future)
it is recommended that you set the 'mountpoint' property of your ZFS
filesystems to 'legacy', and that you manage them using
config.fileSystems, just like any other non-ZFS filesystem is usually
managed in NixOS.
2014-10-22 19:17:21 +02:00
|
|
|
postDeviceCommands = concatStringsSep "\n" ([''
|
|
|
|
ZFS_FORCE="${optionalString cfgZfs.forceImportRoot "-f"}"
|
|
|
|
|
|
|
|
for o in $(cat /proc/cmdline); do
|
|
|
|
case $o in
|
|
|
|
zfs_force|zfs_force=1)
|
|
|
|
ZFS_FORCE="-f"
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
done
|
|
|
|
''] ++ (map (pool: ''
|
|
|
|
echo "importing root ZFS pool \"${pool}\"..."
|
2015-12-12 21:32:38 +01:00
|
|
|
zpool import -d /dev/disk/by-id -N $ZFS_FORCE "${pool}"
|
nixos/zfs: Improve the ZFS boot process
It turns out that the upstream systemd services that import ZFS pools contain
serious bugs. The first major problem is that importing pools fails if there
are no pools to import. The second major problem is that if a pool ends up in
/etc/zfs/zpool.cache but it disappears from the system (e.g. if you
reboot but during the reboot you unplug your ZFS-formatted USB pen drive),
then the import service will always fail and it will be impossible to get rid
of the pool from the cache (unless you manually delete the cache).
Also, the upstream service would always import all available ZFS pools every
boot, which may not be what is desired in some cases.
This commit will solve these problems in the following ways:
1. Ignore /etc/zfs/zpool.cache. This seems to be a major source of
issues, and also does not play well with NixOS's philosophy of
reproducible configurations. Instead, on every boot NixOS will try to import
the set of pools that are specified in its configuration. This is also the
direction that upstream is moving towards.
2. Instead of trying to import all ZFS pools, only import those that are
actually necessary. NixOS will automatically determine these from the
config.fileSystems.* option. Also, the user can import any additional
pools every boot by adding them to the config.boot.zfs.extraPools
option, but this is only necessary if their filesystems are not
specified in config.fileSystems.*.
3. Added options to configure if ZFS should force-import ZFS pools. This may
currently be necessary, especially if your pools have not been correctly
imported with a proper host id configuration (which is probably true for 99% of
current NixOS ZFS users). Once host id configuration becomes mandatory when
using ZFS in NixOS and we are sure that most users have updated their
configurations and rebooted at least once, we should disable force-import by
default. Probably, this shouldn't be done before the next stable release.
WARNING: This commit may change the order in which your non-ZFS vs ZFS
filesystems are mounted. To avoid this problem (now or in the future)
it is recommended that you set the 'mountpoint' property of your ZFS
filesystems to 'legacy', and that you manage them using
config.fileSystems, just like any other non-ZFS filesystem is usually
managed in NixOS.
2014-10-22 19:17:21 +02:00
|
|
|
'') rootPools));
|
2014-01-22 01:11:51 +01:00
|
|
|
};
|
|
|
|
|
2014-08-31 18:18:13 +02:00
|
|
|
boot.loader.grub = mkIf inInitrd {
|
|
|
|
zfsSupport = true;
|
|
|
|
};
|
|
|
|
|
2015-02-08 00:07:30 +01:00
|
|
|
environment.etc."zfs/zed.d".source = "${zfsUserPkg}/etc/zfs/zed.d/*";
|
2013-06-07 18:34:46 +02:00
|
|
|
|
2015-02-08 00:07:30 +01:00
|
|
|
system.fsPackages = [ zfsUserPkg ]; # XXX: needed? zfs doesn't have (need) a fsck
|
|
|
|
environment.systemPackages = [ zfsUserPkg ];
|
|
|
|
services.udev.packages = [ zfsUserPkg ]; # to hook zvol naming, etc.
|
|
|
|
systemd.packages = [ zfsUserPkg ];
|
2014-10-22 18:48:57 +02:00
|
|
|
|
nixos/zfs: Improve the ZFS boot process
It turns out that the upstream systemd services that import ZFS pools contain
serious bugs. The first major problem is that importing pools fails if there
are no pools to import. The second major problem is that if a pool ends up in
/etc/zfs/zpool.cache but it disappears from the system (e.g. if you
reboot but during the reboot you unplug your ZFS-formatted USB pen drive),
then the import service will always fail and it will be impossible to get rid
of the pool from the cache (unless you manually delete the cache).
Also, the upstream service would always import all available ZFS pools every
boot, which may not be what is desired in some cases.
This commit will solve these problems in the following ways:
1. Ignore /etc/zfs/zpool.cache. This seems to be a major source of
issues, and also does not play well with NixOS's philosophy of
reproducible configurations. Instead, on every boot NixOS will try to import
the set of pools that are specified in its configuration. This is also the
direction that upstream is moving towards.
2. Instead of trying to import all ZFS pools, only import those that are
actually necessary. NixOS will automatically determine these from the
config.fileSystems.* option. Also, the user can import any additional
pools every boot by adding them to the config.boot.zfs.extraPools
option, but this is only necessary if their filesystems are not
specified in config.fileSystems.*.
3. Added options to configure if ZFS should force-import ZFS pools. This may
currently be necessary, especially if your pools have not been correctly
imported with a proper host id configuration (which is probably true for 99% of
current NixOS ZFS users). Once host id configuration becomes mandatory when
using ZFS in NixOS and we are sure that most users have updated their
configurations and rebooted at least once, we should disable force-import by
default. Probably, this shouldn't be done before the next stable release.
WARNING: This commit may change the order in which your non-ZFS vs ZFS
filesystems are mounted. To avoid this problem (now or in the future)
it is recommended that you set the 'mountpoint' property of your ZFS
filesystems to 'legacy', and that you manage them using
config.fileSystems, just like any other non-ZFS filesystem is usually
managed in NixOS.
2014-10-22 19:17:21 +02:00
|
|
|
systemd.services = let
|
|
|
|
getPoolFilesystems = pool:
|
|
|
|
filter (x: x.fsType == "zfs" && (fsToPool x) == pool) (attrValues config.fileSystems);
|
|
|
|
|
|
|
|
getPoolMounts = pool:
|
|
|
|
let
|
|
|
|
mountPoint = fs: escapeSystemdPath fs.mountPoint;
|
|
|
|
in
|
|
|
|
map (x: "${mountPoint x}.mount") (getPoolFilesystems pool);
|
|
|
|
|
|
|
|
createImportService = pool:
|
|
|
|
nameValuePair "zfs-import-${pool}" {
|
|
|
|
description = "Import ZFS pool \"${pool}\"";
|
|
|
|
requires = [ "systemd-udev-settle.service" ];
|
|
|
|
after = [ "systemd-udev-settle.service" "systemd-modules-load.service" ];
|
|
|
|
wantedBy = (getPoolMounts pool) ++ [ "local-fs.target" ];
|
|
|
|
before = (getPoolMounts pool) ++ [ "local-fs.target" ];
|
|
|
|
unitConfig = {
|
|
|
|
DefaultDependencies = "no";
|
|
|
|
};
|
|
|
|
serviceConfig = {
|
|
|
|
Type = "oneshot";
|
|
|
|
RemainAfterExit = true;
|
|
|
|
};
|
|
|
|
script = ''
|
2015-02-08 00:07:30 +01:00
|
|
|
zpool_cmd="${zfsUserPkg}/sbin/zpool"
|
2015-12-12 21:32:38 +01:00
|
|
|
("$zpool_cmd" list "${pool}" >/dev/null) || "$zpool_cmd" import -d /dev/disk/by-id -N ${optionalString cfgZfs.forceImportAll "-f"} "${pool}"
|
nixos/zfs: Improve the ZFS boot process
It turns out that the upstream systemd services that import ZFS pools contain
serious bugs. The first major problem is that importing pools fails if there
are no pools to import. The second major problem is that if a pool ends up in
/etc/zfs/zpool.cache but it disappears from the system (e.g. if you
reboot but during the reboot you unplug your ZFS-formatted USB pen drive),
then the import service will always fail and it will be impossible to get rid
of the pool from the cache (unless you manually delete the cache).
Also, the upstream service would always import all available ZFS pools every
boot, which may not be what is desired in some cases.
This commit will solve these problems in the following ways:
1. Ignore /etc/zfs/zpool.cache. This seems to be a major source of
issues, and also does not play well with NixOS's philosophy of
reproducible configurations. Instead, on every boot NixOS will try to import
the set of pools that are specified in its configuration. This is also the
direction that upstream is moving towards.
2. Instead of trying to import all ZFS pools, only import those that are
actually necessary. NixOS will automatically determine these from the
config.fileSystems.* option. Also, the user can import any additional
pools every boot by adding them to the config.boot.zfs.extraPools
option, but this is only necessary if their filesystems are not
specified in config.fileSystems.*.
3. Added options to configure if ZFS should force-import ZFS pools. This may
currently be necessary, especially if your pools have not been correctly
imported with a proper host id configuration (which is probably true for 99% of
current NixOS ZFS users). Once host id configuration becomes mandatory when
using ZFS in NixOS and we are sure that most users have updated their
configurations and rebooted at least once, we should disable force-import by
default. Probably, this shouldn't be done before the next stable release.
WARNING: This commit may change the order in which your non-ZFS vs ZFS
filesystems are mounted. To avoid this problem (now or in the future)
it is recommended that you set the 'mountpoint' property of your ZFS
filesystems to 'legacy', and that you manage them using
config.fileSystems, just like any other non-ZFS filesystem is usually
managed in NixOS.
2014-10-22 19:17:21 +02:00
|
|
|
'';
|
|
|
|
};
|
|
|
|
in listToAttrs (map createImportService dataPools) // {
|
|
|
|
"zfs-mount" = { after = [ "systemd-modules-load.service" ]; };
|
|
|
|
"zfs-share" = { after = [ "systemd-modules-load.service" ]; };
|
|
|
|
"zed" = { after = [ "systemd-modules-load.service" ]; };
|
|
|
|
};
|
|
|
|
|
|
|
|
systemd.targets."zfs-import" =
|
|
|
|
let
|
|
|
|
services = map (pool: "zfs-import-${pool}.service") dataPools;
|
|
|
|
in
|
|
|
|
{
|
|
|
|
requires = services;
|
|
|
|
after = services;
|
|
|
|
};
|
|
|
|
|
2014-10-22 18:48:57 +02:00
|
|
|
systemd.targets."zfs".wantedBy = [ "multi-user.target" ];
|
2014-01-22 01:11:51 +01:00
|
|
|
})
|
|
|
|
|
|
|
|
(mkIf enableAutoSnapshots {
|
|
|
|
systemd.services."zfs-snapshot-frequent" = {
|
|
|
|
description = "ZFS auto-snapshotting every 15 mins";
|
nixos/zfs: Improve the ZFS boot process
It turns out that the upstream systemd services that import ZFS pools contain
serious bugs. The first major problem is that importing pools fails if there
are no pools to import. The second major problem is that if a pool ends up in
/etc/zfs/zpool.cache but it disappears from the system (e.g. if you
reboot but during the reboot you unplug your ZFS-formatted USB pen drive),
then the import service will always fail and it will be impossible to get rid
of the pool from the cache (unless you manually delete the cache).
Also, the upstream service would always import all available ZFS pools every
boot, which may not be what is desired in some cases.
This commit will solve these problems in the following ways:
1. Ignore /etc/zfs/zpool.cache. This seems to be a major source of
issues, and also does not play well with NixOS's philosophy of
reproducible configurations. Instead, on every boot NixOS will try to import
the set of pools that are specified in its configuration. This is also the
direction that upstream is moving towards.
2. Instead of trying to import all ZFS pools, only import those that are
actually necessary. NixOS will automatically determine these from the
config.fileSystems.* option. Also, the user can import any additional
pools every boot by adding them to the config.boot.zfs.extraPools
option, but this is only necessary if their filesystems are not
specified in config.fileSystems.*.
3. Added options to configure if ZFS should force-import ZFS pools. This may
currently be necessary, especially if your pools have not been correctly
imported with a proper host id configuration (which is probably true for 99% of
current NixOS ZFS users). Once host id configuration becomes mandatory when
using ZFS in NixOS and we are sure that most users have updated their
configurations and rebooted at least once, we should disable force-import by
default. Probably, this shouldn't be done before the next stable release.
WARNING: This commit may change the order in which your non-ZFS vs ZFS
filesystems are mounted. To avoid this problem (now or in the future)
it is recommended that you set the 'mountpoint' property of your ZFS
filesystems to 'legacy', and that you manage them using
config.fileSystems, just like any other non-ZFS filesystem is usually
managed in NixOS.
2014-10-22 19:17:21 +02:00
|
|
|
after = [ "zfs-import.target" ];
|
2014-01-22 01:11:51 +01:00
|
|
|
serviceConfig = {
|
|
|
|
Type = "oneshot";
|
|
|
|
ExecStart = "${zfsAutoSnap} frequent ${toString cfgSnapshots.frequent}";
|
|
|
|
};
|
|
|
|
restartIfChanged = false;
|
|
|
|
startAt = "*:15,30,45";
|
|
|
|
};
|
|
|
|
|
|
|
|
systemd.services."zfs-snapshot-hourly" = {
|
|
|
|
description = "ZFS auto-snapshotting every hour";
|
nixos/zfs: Improve the ZFS boot process
It turns out that the upstream systemd services that import ZFS pools contain
serious bugs. The first major problem is that importing pools fails if there
are no pools to import. The second major problem is that if a pool ends up in
/etc/zfs/zpool.cache but it disappears from the system (e.g. if you
reboot but during the reboot you unplug your ZFS-formatted USB pen drive),
then the import service will always fail and it will be impossible to get rid
of the pool from the cache (unless you manually delete the cache).
Also, the upstream service would always import all available ZFS pools every
boot, which may not be what is desired in some cases.
This commit will solve these problems in the following ways:
1. Ignore /etc/zfs/zpool.cache. This seems to be a major source of
issues, and also does not play well with NixOS's philosophy of
reproducible configurations. Instead, on every boot NixOS will try to import
the set of pools that are specified in its configuration. This is also the
direction that upstream is moving towards.
2. Instead of trying to import all ZFS pools, only import those that are
actually necessary. NixOS will automatically determine these from the
config.fileSystems.* option. Also, the user can import any additional
pools every boot by adding them to the config.boot.zfs.extraPools
option, but this is only necessary if their filesystems are not
specified in config.fileSystems.*.
3. Added options to configure if ZFS should force-import ZFS pools. This may
currently be necessary, especially if your pools have not been correctly
imported with a proper host id configuration (which is probably true for 99% of
current NixOS ZFS users). Once host id configuration becomes mandatory when
using ZFS in NixOS and we are sure that most users have updated their
configurations and rebooted at least once, we should disable force-import by
default. Probably, this shouldn't be done before the next stable release.
WARNING: This commit may change the order in which your non-ZFS vs ZFS
filesystems are mounted. To avoid this problem (now or in the future)
it is recommended that you set the 'mountpoint' property of your ZFS
filesystems to 'legacy', and that you manage them using
config.fileSystems, just like any other non-ZFS filesystem is usually
managed in NixOS.
2014-10-22 19:17:21 +02:00
|
|
|
after = [ "zfs-import.target" ];
|
2014-01-22 01:11:51 +01:00
|
|
|
serviceConfig = {
|
|
|
|
Type = "oneshot";
|
|
|
|
ExecStart = "${zfsAutoSnap} hourly ${toString cfgSnapshots.hourly}";
|
|
|
|
};
|
|
|
|
restartIfChanged = false;
|
|
|
|
startAt = "hourly";
|
|
|
|
};
|
|
|
|
|
|
|
|
systemd.services."zfs-snapshot-daily" = {
|
|
|
|
description = "ZFS auto-snapshotting every day";
|
nixos/zfs: Improve the ZFS boot process
It turns out that the upstream systemd services that import ZFS pools contain
serious bugs. The first major problem is that importing pools fails if there
are no pools to import. The second major problem is that if a pool ends up in
/etc/zfs/zpool.cache but it disappears from the system (e.g. if you
reboot but during the reboot you unplug your ZFS-formatted USB pen drive),
then the import service will always fail and it will be impossible to get rid
of the pool from the cache (unless you manually delete the cache).
Also, the upstream service would always import all available ZFS pools every
boot, which may not be what is desired in some cases.
This commit will solve these problems in the following ways:
1. Ignore /etc/zfs/zpool.cache. This seems to be a major source of
issues, and also does not play well with NixOS's philosophy of
reproducible configurations. Instead, on every boot NixOS will try to import
the set of pools that are specified in its configuration. This is also the
direction that upstream is moving towards.
2. Instead of trying to import all ZFS pools, only import those that are
actually necessary. NixOS will automatically determine these from the
config.fileSystems.* option. Also, the user can import any additional
pools every boot by adding them to the config.boot.zfs.extraPools
option, but this is only necessary if their filesystems are not
specified in config.fileSystems.*.
3. Added options to configure if ZFS should force-import ZFS pools. This may
currently be necessary, especially if your pools have not been correctly
imported with a proper host id configuration (which is probably true for 99% of
current NixOS ZFS users). Once host id configuration becomes mandatory when
using ZFS in NixOS and we are sure that most users have updated their
configurations and rebooted at least once, we should disable force-import by
default. Probably, this shouldn't be done before the next stable release.
WARNING: This commit may change the order in which your non-ZFS vs ZFS
filesystems are mounted. To avoid this problem (now or in the future)
it is recommended that you set the 'mountpoint' property of your ZFS
filesystems to 'legacy', and that you manage them using
config.fileSystems, just like any other non-ZFS filesystem is usually
managed in NixOS.
2014-10-22 19:17:21 +02:00
|
|
|
after = [ "zfs-import.target" ];
|
2014-01-22 01:11:51 +01:00
|
|
|
serviceConfig = {
|
|
|
|
Type = "oneshot";
|
|
|
|
ExecStart = "${zfsAutoSnap} daily ${toString cfgSnapshots.daily}";
|
|
|
|
};
|
|
|
|
restartIfChanged = false;
|
|
|
|
startAt = "daily";
|
|
|
|
};
|
|
|
|
|
|
|
|
systemd.services."zfs-snapshot-weekly" = {
|
|
|
|
description = "ZFS auto-snapshotting every week";
|
nixos/zfs: Improve the ZFS boot process
It turns out that the upstream systemd services that import ZFS pools contain
serious bugs. The first major problem is that importing pools fails if there
are no pools to import. The second major problem is that if a pool ends up in
/etc/zfs/zpool.cache but it disappears from the system (e.g. if you
reboot but during the reboot you unplug your ZFS-formatted USB pen drive),
then the import service will always fail and it will be impossible to get rid
of the pool from the cache (unless you manually delete the cache).
Also, the upstream service would always import all available ZFS pools every
boot, which may not be what is desired in some cases.
This commit will solve these problems in the following ways:
1. Ignore /etc/zfs/zpool.cache. This seems to be a major source of
issues, and also does not play well with NixOS's philosophy of
reproducible configurations. Instead, on every boot NixOS will try to import
the set of pools that are specified in its configuration. This is also the
direction that upstream is moving towards.
2. Instead of trying to import all ZFS pools, only import those that are
actually necessary. NixOS will automatically determine these from the
config.fileSystems.* option. Also, the user can import any additional
pools every boot by adding them to the config.boot.zfs.extraPools
option, but this is only necessary if their filesystems are not
specified in config.fileSystems.*.
3. Added options to configure if ZFS should force-import ZFS pools. This may
currently be necessary, especially if your pools have not been correctly
imported with a proper host id configuration (which is probably true for 99% of
current NixOS ZFS users). Once host id configuration becomes mandatory when
using ZFS in NixOS and we are sure that most users have updated their
configurations and rebooted at least once, we should disable force-import by
default. Probably, this shouldn't be done before the next stable release.
WARNING: This commit may change the order in which your non-ZFS vs ZFS
filesystems are mounted. To avoid this problem (now or in the future)
it is recommended that you set the 'mountpoint' property of your ZFS
filesystems to 'legacy', and that you manage them using
config.fileSystems, just like any other non-ZFS filesystem is usually
managed in NixOS.
2014-10-22 19:17:21 +02:00
|
|
|
after = [ "zfs-import.target" ];
|
2014-01-22 01:11:51 +01:00
|
|
|
serviceConfig = {
|
|
|
|
Type = "oneshot";
|
|
|
|
ExecStart = "${zfsAutoSnap} weekly ${toString cfgSnapshots.weekly}";
|
|
|
|
};
|
|
|
|
restartIfChanged = false;
|
|
|
|
startAt = "weekly";
|
|
|
|
};
|
|
|
|
|
|
|
|
systemd.services."zfs-snapshot-monthly" = {
|
|
|
|
description = "ZFS auto-snapshotting every month";
|
nixos/zfs: Improve the ZFS boot process
It turns out that the upstream systemd services that import ZFS pools contain
serious bugs. The first major problem is that importing pools fails if there
are no pools to import. The second major problem is that if a pool ends up in
/etc/zfs/zpool.cache but it disappears from the system (e.g. if you
reboot but during the reboot you unplug your ZFS-formatted USB pen drive),
then the import service will always fail and it will be impossible to get rid
of the pool from the cache (unless you manually delete the cache).
Also, the upstream service would always import all available ZFS pools every
boot, which may not be what is desired in some cases.
This commit will solve these problems in the following ways:
1. Ignore /etc/zfs/zpool.cache. This seems to be a major source of
issues, and also does not play well with NixOS's philosophy of
reproducible configurations. Instead, on every boot NixOS will try to import
the set of pools that are specified in its configuration. This is also the
direction that upstream is moving towards.
2. Instead of trying to import all ZFS pools, only import those that are
actually necessary. NixOS will automatically determine these from the
config.fileSystems.* option. Also, the user can import any additional
pools every boot by adding them to the config.boot.zfs.extraPools
option, but this is only necessary if their filesystems are not
specified in config.fileSystems.*.
3. Added options to configure if ZFS should force-import ZFS pools. This may
currently be necessary, especially if your pools have not been correctly
imported with a proper host id configuration (which is probably true for 99% of
current NixOS ZFS users). Once host id configuration becomes mandatory when
using ZFS in NixOS and we are sure that most users have updated their
configurations and rebooted at least once, we should disable force-import by
default. Probably, this shouldn't be done before the next stable release.
WARNING: This commit may change the order in which your non-ZFS vs ZFS
filesystems are mounted. To avoid this problem (now or in the future)
it is recommended that you set the 'mountpoint' property of your ZFS
filesystems to 'legacy', and that you manage them using
config.fileSystems, just like any other non-ZFS filesystem is usually
managed in NixOS.
2014-10-22 19:17:21 +02:00
|
|
|
after = [ "zfs-import.target" ];
|
2014-01-22 01:11:51 +01:00
|
|
|
serviceConfig = {
|
|
|
|
Type = "oneshot";
|
|
|
|
ExecStart = "${zfsAutoSnap} monthly ${toString cfgSnapshots.monthly}";
|
|
|
|
};
|
|
|
|
restartIfChanged = false;
|
|
|
|
startAt = "monthly";
|
|
|
|
};
|
|
|
|
})
|
|
|
|
];
|
2012-12-04 19:17:54 +01:00
|
|
|
}
|