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 17:17:21 +00:00
{ config , lib , pkgs , utils , . . . }:
2012-12-04 19:57:59 +00:00
#
2019-07-24 12:41:22 +00:00
# TODO: zfs tunables
2012-12-04 18:17:54 +00: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 17:17:21 +00:00
with utils ;
2014-04-14 14:26:48 +00:00
with lib ;
2012-12-04 18:17:54 +00:00
let
2014-03-22 17:27:23 +00:00
cfgZfs = config . boot . zfs ;
2014-01-22 00:11:51 +00:00
cfgSnapshots = config . services . zfs . autoSnapshot ;
2015-03-17 03:32:58 +00:00
cfgSnapFlags = cfgSnapshots . flags ;
2017-03-02 16:13:54 +00:00
cfgScrub = config . services . zfs . autoScrub ;
2019-07-24 12:41:22 +00:00
cfgTrim = config . services . zfs . trim ;
2019-12-04 19:29:19 +00:00
cfgZED = config . services . zfs . zed ;
2014-01-22 00:11:51 +00:00
2012-12-04 18:17:54 +00:00
inInitrd = any ( fs : fs == " z f s " ) config . boot . initrd . supportedFilesystems ;
2012-12-04 19:57:59 +00:00
inSystem = any ( fs : fs == " z f s " ) config . boot . supportedFilesystems ;
2014-01-22 00:11:51 +00:00
autosnapPkg = pkgs . zfstools . override {
2021-01-15 12:13:51 +00:00
zfs = cfgZfs . package ;
2014-01-22 00:11:51 +00:00
} ;
zfsAutoSnap = " ${ autosnapPkg } / b i n / z f s - a u t o - s n a p s h o t " ;
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 17:17:21 +00:00
datasetToPool = x : elemAt ( splitString " / " x ) 0 ;
fsToPool = fs : datasetToPool fs . device ;
2015-11-25 19:09:09 +00:00
zfsFilesystems = filter ( x : x . fsType == " z f s " ) config . system . build . fileSystems ;
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 17:17:21 +00:00
allPools = unique ( ( map fsToPool zfsFilesystems ) ++ cfgZfs . extraPools ) ;
2016-08-23 18:01:35 +00:00
rootPools = unique ( map fsToPool ( filter fsNeededForBoot zfsFilesystems ) ) ;
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 17:17:21 +00:00
dataPools = unique ( filter ( pool : ! ( elem pool rootPools ) ) allPools ) ;
2015-03-20 02:49:25 +00:00
snapshotNames = [ " f r e q u e n t " " h o u r l y " " d a i l y " " w e e k l y " " m o n t h l y " ] ;
2018-06-16 01:39:07 +00:00
# When importing ZFS pools, there's one difficulty: These scripts may run
# before the backing devices (physical HDDs, etc.) of the pool have been
# scanned and initialized.
#
# An attempted import with all devices missing will just fail, and can be
# retried, but an import where e.g. two out of three disks in a three-way
# mirror are missing, will succeed. This is a problem: When the missing disks
# are later discovered, they won't be automatically set online, rendering the
# pool redundancy-less (and far slower) until such time as the system reboots.
#
# The solution is the below. poolReady checks the status of an un-imported
# pool, to see if *every* device is available -- in which case the pool will be
# in state ONLINE, as opposed to DEGRADED, FAULTED or MISSING.
#
# The import scripts then loop over this, waiting until the pool is ready or a
# sufficient amount of time has passed that we can assume it won't be. In the
# latter case it makes one last attempt at importing, allowing the system to
# (eventually) boot even with a degraded pool.
importLib = { zpoolCmd , awkCmd , cfgZfs }: ''
poolReady ( ) {
pool = " $ 1 "
2018-10-16 09:45:25 +00:00
state = " $ ( " $ { zpoolCmd } " i m p o r t 2 > / d e v / n u l l | " $ { awkCmd } " " /pool : $ pool / { found = 1 } ; /state : / { if ( found == 1 ) { print \ $ 2 ; exit } } ; END { if ( found == 0 ) { print \ " M I S S I N G \" } } " ) "
2018-06-16 01:39:07 +00:00
if [ [ " $ s t a t e " = " O N L I N E " ] ] ; then
return 0
else
echo " P o o l $ p o o l i n s t a t e $ s t a t e , w a i t i n g "
return 1
fi
}
poolImported ( ) {
pool = " $ 1 "
" ${ zpoolCmd } " list " $ p o o l " > /dev/null 2 > /dev/null
}
poolImport ( ) {
pool = " $ 1 "
" ${ zpoolCmd } " import - d " ${ cfgZfs . devNodes } " - N $ ZFS_FORCE " $ p o o l "
}
'' ;
2019-12-04 19:29:19 +00:00
zedConf = generators . toKeyValue {
mkKeyValue = generators . mkKeyValueDefault {
mkValueString = v :
if isInt v then toString v
else if isString v then " \" ${ v } \" "
else if true == v then " 1 "
else if false == v then " 0 "
else if isList v then " \" " + ( concatStringsSep " " v ) + " \" "
else err " t h i s v a l u e i s " ( toString v ) ;
} " = " ;
} cfgZED . settings ;
2012-12-04 18:17:54 +00:00
in
{
2019-12-10 01:51:19 +00:00
imports = [
( mkRemovedOptionModule [ " b o o t " " z f s " " e n a b l e L e g a c y C r y p t o " ] " T h e c o r r e s p o n d i n g p a c k a g e w a s r e m o v e d f r o m n i x p k g s . " )
] ;
2012-12-04 19:57:59 +00:00
###### interface
2014-01-22 00:11:51 +00: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 17:17:21 +00:00
boot . zfs = {
2021-01-15 12:13:51 +00:00
package = mkOption {
readOnly = true ;
type = types . package ;
default = if config . boot . zfs . enableUnstable then pkgs . zfsUnstable else pkgs . zfs ;
2021-05-13 21:40:10 +00:00
defaultText = " i f c o n f i g . b o o t . z f s . e n a b l e U n s t a b l e t h e n p k g s . z f s U n s t a b l e e l s e p k g s . z f s " ;
2021-01-15 12:13:51 +00:00
description = " C o n f i g u r e d Z F S u s e r l a n d t o o l s p a c k a g e . " ;
} ;
2021-01-15 12:18:34 +00:00
enabled = mkOption {
readOnly = true ;
type = types . bool ;
default = inInitrd || inSystem ;
description = " T r u e i f Z F S f i l e s y s t e m s u p p o r t i s e n a b l e d " ;
} ;
2017-09-12 23:28:42 +00:00
enableUnstable = mkOption {
type = types . bool ;
default = false ;
description = ''
Use the unstable zfs package . This might be an option , if the latest
kernel is not yet supported by a published release of ZFS . Enabling
this option will install a development version of ZFS on Linux . The
version will have already passed an extensive test suite , but it is
more likely to hit an undiscovered bug compared to running a released
version of ZFS on Linux .
'' ;
} ;
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 17:17:21 +00:00
extraPools = mkOption {
type = types . listOf types . str ;
default = [ ] ;
example = [ " t a n k " " d a t a " ] ;
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 .
'' ;
} ;
2015-12-22 23:29:47 +00:00
devNodes = mkOption {
type = types . path ;
2015-12-22 23:33:06 +00:00
default = " / d e v / d i s k / b y - i d " ;
2015-12-22 23:29:47 +00:00
example = " / d e v / d i s k / b y - i d " ;
description = ''
Name of directory from which to import ZFS devices .
2016-04-15 16:25:32 +00:00
This should be a path under /dev containing stable names for all devices needed , as
import may fail if device nodes are renamed concurrently with a device failing .
2015-12-22 23:29:47 +00: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 17:17:21 +00:00
forceImportRoot = mkOption {
type = types . bool ;
default = true ;
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 ;
2020-09-12 23:17:37 +00:00
default = false ;
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 17:17:21 +00:00
description = ''
Forcibly import all ZFS pool ( s ) .
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
" z p o o l i m p o r t - f & l t ; p o o l - n a m e & g t ; " , and then reboot . You should only need to do
this once .
'' ;
} ;
2017-09-15 15:18:09 +00:00
requestEncryptionCredentials = mkOption {
2020-07-18 07:16:41 +00:00
type = types . either types . bool ( types . listOf types . str ) ;
2019-07-04 21:11:52 +00:00
default = true ;
2020-07-18 07:16:41 +00:00
example = [ " t a n k " " d a t a " ] ;
2017-09-15 15:18:09 +00:00
description = ''
2020-07-18 07:16:41 +00:00
If true on import encryption keys or passwords for all encrypted datasets
are requested . To only decrypt selected datasets supply a list of dataset
names instead . For root pools the encryption key can be supplied via both
an interactive prompt ( keylocation = prompt ) and from a file ( keylocation = file:// ) .
2017-09-15 15:18:09 +00:00
'' ;
} ;
2014-03-22 17:27:23 +00:00
} ;
2014-01-22 00:11:51 +00: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 18:17:54 +00:00
2014-01-22 00:11:51 +00: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 18:17:54 +00:00
2015-03-17 03:32:58 +00:00
flags = mkOption {
default = " - k - p " ;
example = " - k - p - - u t c " ;
type = types . str ;
description = ''
Flags to pass to the zfs-auto-snapshot command .
Run <literal> zfs-auto-snapshot < /literal > ( without any arguments ) to
see available flags .
If it's not too inconvenient for snapshots to have timestamps in UTC ,
it is suggested that you append <literal> - - utc < /literal > to the list
of default options ( see example ) .
Otherwise , snapshot names can cause name conflicts or apparent time
reversals due to daylight savings , timezone or other date/time changes .
'' ;
} ;
2014-01-22 00:11:51 +00:00
frequent = mkOption {
default = 4 ;
type = types . int ;
description = ''
Number of frequent ( 1 5 - 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 18:17:54 +00:00
2014-01-22 00:11:51 +00:00
weekly = mkOption {
default = 4 ;
type = types . int ;
description = ''
Number of weekly auto-snapshots that you wish to keep .
2012-12-04 19:57:59 +00:00
'' ;
2014-01-22 00:11:51 +00:00
} ;
monthly = mkOption {
default = 12 ;
type = types . int ;
description = ''
Number of monthly auto-snapshots that you wish to keep .
2012-12-04 19:57:59 +00:00
'' ;
2014-01-22 00:11:51 +00:00
} ;
2012-12-04 19:57:59 +00:00
} ;
2017-03-02 16:13:54 +00:00
2019-07-24 12:41:22 +00:00
services . zfs . trim = {
2019-09-27 17:24:23 +00:00
enable = mkOption {
description = " W h e t h e r t o e n a b l e p e r i o d i c T R I M o n a l l Z F S p o o l s . " ;
default = true ;
example = false ;
type = types . bool ;
} ;
2019-07-24 12:41:22 +00:00
interval = mkOption {
default = " w e e k l y " ;
type = types . str ;
example = " d a i l y " ;
2017-03-02 16:13:54 +00:00
description = ''
2019-07-24 12:41:22 +00:00
How often we run trim . For most desktop and server systems
a sufficient trimming frequency is once a week .
The format is described in
<citerefentry> <refentrytitle> systemd . time < /refentrytitle >
<manvolnum> 7 < /manvolnum > < /citerefentry > .
2017-03-02 16:13:54 +00:00
'' ;
} ;
2019-07-24 12:41:22 +00:00
} ;
services . zfs . autoScrub = {
2021-02-26 17:15:58 +00:00
enable = mkEnableOption " p e r i o d i c s c r u b b i n g o f Z F S p o o l s " ;
2017-03-02 16:13:54 +00:00
interval = mkOption {
default = " S u n , 0 2 : 0 0 " ;
type = types . str ;
example = " d a i l y " ;
description = ''
Systemd calendar expression when to scrub ZFS pools . See
<citerefentry> <refentrytitle> systemd . time < /refentrytitle >
2017-03-21 07:27:56 +00:00
<manvolnum> 7 < /manvolnum > < /citerefentry > .
2017-03-02 16:13:54 +00:00
'' ;
} ;
pools = mkOption {
default = [ ] ;
type = types . listOf types . str ;
example = [ " t a n k " ] ;
description = ''
List of ZFS pools to periodically scrub . If empty , all pools
will be scrubbed .
'' ;
} ;
} ;
2019-12-04 19:29:19 +00:00
2021-01-14 07:38:19 +00:00
services . zfs . zed = {
2021-01-14 07:40:46 +00:00
enableMail = mkEnableOption " Z E D ' s a b i l i t y t o s e n d e m a i l s " // {
default = cfgZfs . package . enableMail ;
} ;
2019-12-04 19:29:19 +00:00
2021-01-14 07:38:19 +00:00
settings = mkOption {
type = with types ; attrsOf ( oneOf [ str int bool ( listOf str ) ] ) ;
example = literalExample ''
{
ZED_DEBUG_LOG = " / t m p / z e d . d e b u g . l o g " ;
2019-12-04 19:29:19 +00:00
2021-01-14 07:38:19 +00:00
ZED_EMAIL_ADDR = [ " r o o t " ] ;
ZED_EMAIL_PROG = " m a i l " ;
ZED_EMAIL_OPTS = " - s ' @ S U B J E C T @ ' @ A D D R E S S @ " ;
2019-12-04 19:29:19 +00:00
2021-01-14 07:38:19 +00:00
ZED_NOTIFY_INTERVAL_SECS = 3600 ;
ZED_NOTIFY_VERBOSE = false ;
ZED_USE_ENCLOSURE_LEDS = true ;
ZED_SCRUB_AFTER_RESILVER = false ;
}
'' ;
description = ''
ZFS Event Daemon /etc/zfs/zed.d/zed.rc content
See
<citerefentry> <refentrytitle> zed < /refentrytitle > <manvolnum> 8 < /manvolnum > < /citerefentry >
for details on ZED and the scripts in /etc/zfs/zed.d to find the possible variables
'' ;
} ;
2019-12-04 19:29:19 +00:00
} ;
2014-01-22 00:11:51 +00:00
} ;
2012-12-04 18:17:54 +00:00
2014-01-22 00:11:51 +00:00
###### implementation
config = mkMerge [
2021-01-15 12:18:34 +00:00
( mkIf cfgZfs . enabled {
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 17:17:21 +00:00
assertions = [
2021-01-14 07:40:46 +00:00
{
assertion = cfgZED . enableMail -> cfgZfs . package . enableMail ;
message = ''
To allow ZED to send emails , ZFS needs to be configured to enable
this . To do so , one must override the ` zfs ` package and set
` enableMail ` to true .
'' ;
}
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 02:59:06 +00:00
{
assertion = config . networking . hostId != null ;
2017-12-20 22:56:03 +00:00
message = " Z F S r e q u i r e s n e t w o r k i n g . h o s t I d t o b e s e t " ;
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 02:59:06 +00: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 17:17:21 +00:00
{
assertion = ! cfgZfs . forceImportAll || cfgZfs . forceImportRoot ;
message = " I f y o u e n a b l e b o o t . z f s . f o r c e I m p o r t A l l , y o u m u s t a l s o e n a b l e b o o t . z f s . f o r c e I m p o r t R o o t " ;
}
] ;
2014-01-22 00:11:51 +00:00
boot = {
2019-06-06 08:24:11 +00:00
kernelModules = [ " z f s " ] ;
2021-01-15 12:13:51 +00:00
extraModulePackages = [
( if config . boot . zfs . enableUnstable then
config . boot . kernelPackages . zfsUnstable
else
config . boot . kernelPackages . zfs )
] ;
2014-01-22 00:11:51 +00:00
} ;
boot . initrd = mkIf inInitrd {
2018-08-13 18:40:45 +00:00
kernelModules = [ " z f s " ] ++ optional ( ! cfgZfs . enableUnstable ) " s p l " ;
2014-01-22 00:11:51 +00:00
extraUtilsCommands =
''
2021-01-15 12:13:51 +00:00
copy_bin_and_libs $ { cfgZfs . package } /sbin/zfs
copy_bin_and_libs $ { cfgZfs . package } /sbin/zdb
copy_bin_and_libs $ { cfgZfs . package } /sbin/zpool
2015-03-29 00:15:41 +00:00
'' ;
extraUtilsCommandsTest = mkIf inInitrd
''
$ out/bin/zfs - - help > /dev/null 2 > & 1
$ out/bin/zpool - - help > /dev/null 2 > & 1
2014-01-22 00:11:51 +00: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 17:17:21 +00: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
2018-06-16 01:39:07 +00:00
'' ] + + [ ( i m p o r t L i b {
# See comments at importLib definition.
zpoolCmd = " z p o o l " ;
awkCmd = " a w k " ;
inherit cfgZfs ;
} ) ] ++ ( map ( pool : ''
2016-07-13 00:18:48 +00:00
echo - n " i m p o r t i n g r o o t Z F S p o o l \" ${ pool } \" . . . "
2018-06-16 01:39:07 +00:00
# Loop across the import until it succeeds, because the devices needed may not be discovered yet.
if ! poolImported " ${ pool } " ; then
for trial in ` seq 1 60 ` ; do
poolReady " ${ pool } " > /dev/null && msg = " $ ( p o o l I m p o r t " $ { pool } " 2 > & 1 ) " && break
sleep 1
echo - n .
done
echo
if [ [ - n " $ m s g " ] ] ; then
echo " $ m s g " ;
2016-07-13 00:18:48 +00:00
fi
2018-06-16 01:39:07 +00:00
poolImported " ${ pool } " || poolImport " ${ pool } " # Try one last time, e.g. to import a degraded pool.
fi
2020-07-18 07:16:41 +00:00
$ { if isBool cfgZfs . requestEncryptionCredentials
then optionalString cfgZfs . requestEncryptionCredentials ''
zfs load-key - a
''
else concatMapStrings ( fs : ''
zfs load-key $ { fs }
'' ) c f g Z f s . r e q u e s t E n c r y p t i o n C r e d e n t i a l s }
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 17:17:21 +00:00
'' ) r o o t P o o l s ) ) ;
2014-01-22 00:11:51 +00:00
} ;
2021-03-20 22:56:32 +00:00
# TODO FIXME See https://github.com/NixOS/nixpkgs/pull/99386#issuecomment-798813567. To not break people's bootloader and as probably not everybody would read release notes that thoroughly add inSystem.
boot . loader . grub = mkIf ( inInitrd || inSystem ) {
2014-08-31 16:18:13 +00:00
zfsSupport = true ;
} ;
2019-12-04 19:29:19 +00:00
services . zfs . zed . settings = {
2021-01-14 07:38:19 +00:00
ZED_EMAIL_PROG = mkIf cfgZED . enableMail ( mkDefault " ${ pkgs . mailutils } / b i n / m a i l " ) ;
2020-05-18 09:25:00 +00:00
PATH = lib . makeBinPath [
2021-01-15 12:13:51 +00:00
cfgZfs . package
2020-05-18 09:25:00 +00:00
pkgs . coreutils
pkgs . curl
pkgs . gawk
pkgs . gnugrep
pkgs . gnused
pkgs . nettools
2020-11-24 15:29:28 +00:00
pkgs . util-linux
2020-05-18 09:25:00 +00:00
] ;
2019-12-04 19:29:19 +00:00
} ;
environment . etc = genAttrs
( map
( file : " z f s / z e d . d / ${ file } " )
[
" a l l - s y s l o g . s h "
" p o o l _ i m p o r t - l e d . s h "
" r e s i l v e r _ f i n i s h - s t a r t - s c r u b . s h "
" s t a t e c h a n g e - l e d . s h "
" v d e v _ a t t a c h - l e d . s h "
" z e d - f u n c t i o n s . s h "
" d a t a - n o t i f y . s h "
" r e s i l v e r _ f i n i s h - n o t i f y . s h "
" s c r u b _ f i n i s h - n o t i f y . s h "
" s t a t e c h a n g e - n o t i f y . s h "
" v d e v _ c l e a r - l e d . s h "
]
)
2021-01-15 12:13:51 +00:00
( file : { source = " ${ cfgZfs . package } / e t c / ${ file } " ; } )
2019-12-04 19:29:19 +00:00
// {
" z f s / z e d . d / z e d . r c " . text = zedConf ;
2021-01-15 12:13:51 +00:00
" z f s / z p o o l . d " . source = " ${ cfgZfs . package } / e t c / z f s / z p o o l . d / " ;
2019-12-04 19:29:19 +00:00
} ;
2013-06-07 16:34:46 +00:00
2021-01-15 12:13:51 +00:00
system . fsPackages = [ cfgZfs . package ] ; # XXX: needed? zfs doesn't have (need) a fsck
environment . systemPackages = [ cfgZfs . package ]
2019-10-08 11:10:23 +00:00
++ optional cfgSnapshots . enable autosnapPkg ; # so the user can run the command to see flags
2015-03-17 03:32:58 +00:00
2021-01-15 12:13:51 +00:00
services . udev . packages = [ cfgZfs . package ] ; # to hook zvol naming, etc.
systemd . packages = [ cfgZfs . package ] ;
2014-10-22 16:48:57 +00: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 17:17:21 +00:00
systemd . services = let
getPoolFilesystems = pool :
2015-11-25 19:09:09 +00:00
filter ( x : x . fsType == " z f s " && ( fsToPool x ) == pool ) config . system . build . fileSystems ;
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 17:17:21 +00:00
getPoolMounts = pool :
let
mountPoint = fs : escapeSystemdPath fs . mountPoint ;
in
map ( x : " ${ mountPoint x } . m o u n t " ) ( getPoolFilesystems pool ) ;
createImportService = pool :
nameValuePair " z f s - i m p o r t - ${ pool } " {
description = " I m p o r t Z F S p o o l \" ${ pool } \" " ;
2017-04-29 06:50:52 +00:00
# we need systemd-udev-settle until https://github.com/zfsonlinux/zfs/pull/4943 is merged
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 17:17:21 +00:00
requires = [ " s y s t e m d - u d e v - s e t t l e . s e r v i c e " ] ;
2020-06-23 10:08:40 +00:00
after = [
" s y s t e m d - u d e v - s e t t l e . s e r v i c e "
" s y s t e m d - m o d u l e s - l o a d . s e r v i c e "
" s y s t e m d - a s k - p a s s w o r d - c o n s o l e . s e r v i c e "
] ;
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 17:17:21 +00:00
wantedBy = ( getPoolMounts pool ) ++ [ " l o c a l - f s . t a r g e t " ] ;
before = ( getPoolMounts pool ) ++ [ " l o c a l - f s . t a r g e t " ] ;
unitConfig = {
DefaultDependencies = " n o " ;
} ;
serviceConfig = {
Type = " o n e s h o t " ;
RemainAfterExit = true ;
} ;
2020-08-18 13:05:56 +00:00
environment . ZFS_FORCE = optionalString cfgZfs . forceImportAll " - f " ;
2018-06-16 01:39:07 +00:00
script = ( importLib {
# See comments at importLib definition.
2021-01-15 12:13:51 +00:00
zpoolCmd = " ${ cfgZfs . package } / s b i n / z p o o l " ;
2021-02-03 10:40:51 +00:00
awkCmd = " ${ pkgs . gawk } / b i n / a w k " ;
2018-06-16 01:39:07 +00:00
inherit cfgZfs ;
} ) + ''
poolImported " ${ pool } " && exit
echo - n " i m p o r t i n g Z F S p o o l \" ${ pool } \" . . . "
# Loop across the import until it succeeds, because the devices needed may not be discovered yet.
for trial in ` seq 1 60 ` ; do
poolReady " ${ pool } " && poolImport " ${ pool } " && break
sleep 1
done
poolImported " ${ pool } " || poolImport " ${ pool } " # Try one last time, e.g. to import a degraded pool.
if poolImported " ${ pool } " ; then
2020-07-18 07:16:41 +00:00
$ { optionalString ( if isBool cfgZfs . requestEncryptionCredentials
then cfgZfs . requestEncryptionCredentials
else cfgZfs . requestEncryptionCredentials != [ ] ) ''
2021-02-03 10:45:31 +00:00
$ { cfgZfs . package } /sbin/zfs list - rHo name , keylocation $ { pool } | while IFS = $ ' \ t' read ds kl ; do
2020-07-18 07:16:41 +00:00
( $ { optionalString ( ! isBool cfgZfs . requestEncryptionCredentials ) ''
if ! echo ' $ { concatStringsSep " \n " cfgZfs . requestEncryptionCredentials } ' | grep - qFx " $ d s " ; then
continue
fi
'' }
case " $ k l " in
2020-06-23 10:08:40 +00:00
none )
; ;
prompt )
2021-02-03 10:45:31 +00:00
$ { config . systemd . package } /bin/systemd-ask-password " E n t e r k e y f o r $ d s : " | $ { cfgZfs . package } /sbin/zfs load-key " $ d s "
2020-06-23 10:08:40 +00:00
; ;
* )
2021-02-03 10:45:31 +00:00
$ { cfgZfs . package } /sbin/zfs load-key " $ d s "
2020-06-23 10:08:40 +00:00
; ;
2020-07-01 01:35:35 +00:00
esac ) < /dev/null # To protect while read ds kl in case anything reads stdin
2020-06-23 10:08:40 +00:00
done
'' }
2018-06-16 01:39:07 +00:00
echo " S u c c e s s f u l l y i m p o r t e d ${ pool } "
else
exit 1
fi
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 17:17:21 +00:00
'' ;
} ;
2016-07-19 07:57:13 +00:00
# This forces a sync of any ZFS pools prior to poweroff, even if they're set
# to sync=disabled.
createSyncService = pool :
nameValuePair " z f s - s y n c - ${ pool } " {
description = " S y n c Z F S p o o l \" ${ pool } \" " ;
wantedBy = [ " s h u t d o w n . t a r g e t " ] ;
2018-06-08 23:06:22 +00:00
unitConfig = {
DefaultDependencies = false ;
} ;
2016-07-19 07:57:13 +00:00
serviceConfig = {
Type = " o n e s h o t " ;
RemainAfterExit = true ;
} ;
script = ''
2021-01-15 12:13:51 +00:00
$ { cfgZfs . package } /sbin/zfs set nixos:shutdown-time= " $ ( d a t e ) " " ${ pool } "
2016-07-19 07:57:13 +00:00
'' ;
} ;
2018-06-13 10:38:15 +00:00
createZfsService = serv :
nameValuePair serv {
after = [ " s y s t e m d - m o d u l e s - l o a d . s e r v i c e " ] ;
wantedBy = [ " z f s . t a r g e t " ] ;
} ;
2016-07-19 07:57:13 +00:00
2018-06-13 10:38:15 +00:00
in listToAttrs ( map createImportService dataPools ++
map createSyncService allPools ++
map createZfsService [ " z f s - m o u n t " " z f s - s h a r e " " z f s - z e d " ] ) ;
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 17:17:21 +00:00
2019-08-13 21:52:01 +00:00
systemd . targets . zfs-import =
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 17:17:21 +00:00
let
services = map ( pool : " z f s - i m p o r t - ${ pool } . s e r v i c e " ) dataPools ;
in
{
requires = services ;
after = services ;
2018-06-15 18:54:49 +00:00
wantedBy = [ " z f s . t a r g e t " ] ;
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 17:17:21 +00:00
} ;
2019-08-13 21:52:01 +00:00
systemd . targets . zfs . wantedBy = [ " m u l t i - u s e r . t a r g e t " ] ;
2014-01-22 00:11:51 +00:00
} )
2021-01-15 12:18:34 +00:00
( mkIf ( cfgZfs . enabled && cfgSnapshots . enable ) {
2015-03-20 02:49:25 +00:00
systemd . services = let
descr = name : if name == " f r e q u e n t " then " 1 5 m i n s "
else if name == " h o u r l y " then " h o u r "
else if name == " d a i l y " then " d a y "
else if name == " w e e k l y " then " w e e k "
else if name == " m o n t h l y " then " m o n t h "
else throw " u n k n o w n s n a p s h o t n a m e " ;
numSnapshots = name : builtins . getAttr name cfgSnapshots ;
in builtins . listToAttrs ( map ( snapName :
{
name = " z f s - s n a p s h o t - ${ snapName } " ;
value = {
description = " Z F S a u t o - s n a p s h o t t i n g e v e r y ${ descr snapName } " ;
after = [ " z f s - i m p o r t . t a r g e t " ] ;
serviceConfig = {
Type = " o n e s h o t " ;
ExecStart = " ${ zfsAutoSnap } ${ cfgSnapFlags } ${ snapName } ${ toString ( numSnapshots snapName ) } " ;
} ;
restartIfChanged = false ;
} ;
} ) snapshotNames ) ;
systemd . timers = let
2018-04-11 14:42:28 +00:00
timer = name : if name == " f r e q u e n t " then " * : 0 , 1 5 , 3 0 , 4 5 " else name ;
2015-03-20 02:49:25 +00:00
in builtins . listToAttrs ( map ( snapName :
{
name = " z f s - s n a p s h o t - ${ snapName } " ;
value = {
wantedBy = [ " t i m e r s . t a r g e t " ] ;
timerConfig = {
OnCalendar = timer snapName ;
Persistent = " y e s " ;
} ;
} ;
} ) snapshotNames ) ;
2014-01-22 00:11:51 +00:00
} )
2017-03-02 16:13:54 +00:00
2021-01-15 12:18:34 +00:00
( mkIf ( cfgZfs . enabled && cfgScrub . enable ) {
2017-03-02 16:13:54 +00:00
systemd . services . zfs-scrub = {
description = " Z F S p o o l s s c r u b b i n g " ;
after = [ " z f s - i m p o r t . t a r g e t " ] ;
serviceConfig = {
Type = " o n e s h o t " ;
} ;
script = ''
2021-01-15 12:13:51 +00:00
$ { cfgZfs . package } /bin/zpool scrub $ {
2017-03-02 16:13:54 +00:00
if cfgScrub . pools != [ ] then
( concatStringsSep " " cfgScrub . pools )
else
2021-01-15 12:13:51 +00:00
" $ ( ${ cfgZfs . package } / b i n / z p o o l l i s t - H - o n a m e ) "
2017-03-02 16:13:54 +00:00
}
'' ;
} ;
systemd . timers . zfs-scrub = {
wantedBy = [ " t i m e r s . t a r g e t " ] ;
2019-01-14 19:55:37 +00:00
after = [ " m u l t i - u s e r . t a r g e t " ] ; # Apparently scrubbing before boot is complete hangs the system? #53583
2017-03-02 16:13:54 +00:00
timerConfig = {
OnCalendar = cfgScrub . interval ;
Persistent = " y e s " ;
} ;
} ;
} )
2019-07-24 12:41:22 +00:00
2021-01-15 12:18:34 +00:00
( mkIf ( cfgZfs . enabled && cfgTrim . enable ) {
2019-07-24 12:41:22 +00:00
systemd . services . zpool-trim = {
description = " Z F S p o o l s t r i m " ;
after = [ " z f s - i m p o r t . t a r g e t " ] ;
2021-01-15 12:13:51 +00:00
path = [ cfgZfs . package ] ;
2019-07-24 12:41:22 +00:00
startAt = cfgTrim . interval ;
2020-03-03 11:19:59 +00:00
# By default we ignore errors returned by the trim command, in case:
# - HDDs are mixed with SSDs
# - There is a SSDs in a pool that is currently trimmed.
# - There are only HDDs and we would set the system in a degraded state
2021-01-24 09:19:10 +00:00
serviceConfig . ExecStart = " ${ pkgs . runtimeShell } - c ' f o r p o o l i n $ ( z p o o l l i s t - H - o n a m e ) ; d o z p o o l t r i m $ p o o l ; d o n e | | t r u e ' " ;
2019-07-24 12:41:22 +00:00
} ;
2021-01-16 04:20:23 +00:00
systemd . timers . zpool-trim . timerConfig . Persistent = " y e s " ;
2019-07-24 12:41:22 +00:00
} )
2014-01-22 00:11:51 +00:00
] ;
2012-12-04 18:17:54 +00:00
}