In reply to @tumble1999:matrix.org
Or can filesystems still be used

In reply to @ginkogruen:matrix.org
Yes you can still use that. Disko is more about the initial partitioning than everything relating to file systems especially concerning network shares.

In reply to @tumble1999:matrix.org
How come it can do tmpfs though?

I want to leverage disko to create datasets for me post-install/initial set-up. I found this suggestion on discourse, and that works for those who've get all their disko config in 1x file (or 1x file that imports all/any other) per machine.
https://discourse.nixos.org/t/add-dataset-to-pool-after-creation-in-disko/62244/2

I don't have my disko config conveniently collated into a variable like that, so I'm wondering how I can achieve something like the below w/disko (the below gives error: stack overflow; max-call-depth exceeded error)?

{
  _file = ./auto-create.nix;
  flake.modules.nixos."nas-2024" =
    {
      config,
      pkgs,
      lib,
      ...
    }:
    let
      preStart =
        # bash
        ''${lib.getExe pkgs.disko} --mode format ${
          pkgs.writeText "disko.nix" (lib.generators.toPretty { } { inherit (config) disko; })
        }'';
    in
    {
      # Perform the "create new datasets/zvols" operation
      systemd.services."zfs-import-tank".preStart = preStart;
      # systemd.services."zfs-import-nvmepool".preStart = preStart; # Don't need this yet
    };
}

PS: I make heavy use of https://flake.parts/options/flake-parts-modules.html, which allow me to split configuration like shown above easily across files

Would any of you have any opinion on which of these two alternatives are better/safer/preferable?

{
  _file = ./auto-create.nix;
  flake.modules.nixos."nas-2024" =
    { config, lib, ... }:
    let
      # https://discourse.nixos.org/t/configure-zfs-filesystems-after-install/48633/2
      zfsDatasets =
        config.disko.devices.zpool
        |> lib.attrsToList
        |> lib.foldl' (
          acc: zpool:
          acc
          ++ (
            zpool.value.datasets
            |> lib.attrValues
            |> lib.filter (dataset: dataset.name != "__root")
            |> lib.map (dataset: {
              zpool = zpool.name;
              inherit (dataset) name mountpoint;
              creationScript = dataset._create;
            })
          )
        ) [ ];
      diskoFormatScript = lib.getExe config.system.build.formatScript;
    in
    {
      # Perform the "create new datasets/zvols" operation
      systemd.services = {
        "zfs-import-tank".preStart = diskoFormatScript;
        # "zfs-import-nvmepool".preStart = diskoFormatScript; # Don't need this yet
      }
      // (
        zfsDatasets
        |> lib.filter (dataset: dataset.name == "doesn't exist") # Disable for now
        |> lib.map (
          dataset:
          lib.nameValuePair "zfs-create-${dataset.zpool}-${lib.replaceString "/" "_" dataset.name}" {
            unitConfig.DefaultDependencies = false;
            requiredBy = [ "local-fs.target" ];
            before = [ "local-fs.target" ];
            after = [
              "zfs-import-${dataset.zpool}.service"
              "zfs-mount.service"
            ];
            unitConfig.ConditionPathIsMountPoint = lib.mkIf (
              dataset.mountpoint != null
            ) "!${dataset.mountpoint}";
            script = dataset.creationScript;
          }
        )
        |> lib.listToAttrs
      );
    };
}

In my opinion Disko would benefit from natively supporting this kind of thing---I have run into this too, and when tweaking my dataset properties it is a pain to try to keep them in sync with my Disko config.

One idea is to have a boolean dataset attribute datasets.<name>.followConfig or similar. If this is set, then on activation (and boot) Disko will try to set the dataset properties to match the config.

Balancing idempotency with the desire to not lose data accidentally is tricky---if you delete a dataset from your config, should Disko delete the dataset from your pool? One idea is to use a custom ZFS user property to identify datasets which are being managed by Disko; this would allow deleting dataset which no longer appear in yoru config, while keeping the ability for people to manually create unmanaged datasets

In my opinion Disko would benefit from natively supporting this kind of thing---I have run into this too, and when tweaking my dataset properties it is a pain to try to keep them in sync with my Disko config.

One idea is to have a boolean dataset attribute datasets.<name>.followConfig or similar. If this is set, then on activation (and boot) Disko will try to set the dataset properties to match the config.

Balancing idempotency with the desire to not lose data accidentally is tricky---if you delete a dataset from your config, should Disko delete the dataset from your pool? One idea is to use a custom ZFS user property to identify datasets which are being managed by Disko; this would allow deleting datasets which no longer appear in your config, while keeping the ability for people to manually create unmanaged datasets

In my opinion Disko would benefit from natively supporting this kind of thing---I have run into this too, and when tweaking my dataset properties it is a pain to try to keep them in sync with my Disko config.

One idea is to have a boolean dataset attribute datasets.<name>.managed or similar. If this is set, then on activation (and boot) Disko will try to set the dataset properties to match the config.

Balancing idempotency with the desire to not lose data accidentally is tricky---if you delete a dataset from your config, should Disko delete the dataset from your pool? One idea is to use a custom ZFS user property to identify datasets which are being managed by Disko; this would allow deleting datasets which no longer appear in your config, while keeping the ability for people to manually create unmanaged datasets