lassulus

hmm, I want to avoid users to define functions in disko, we use the ability to serialize the config to/from json. also we cant type validate it anymore. maybe we...

how about we change the field from zfs_member_tag to just to name? and in topology we can do something like that: ``` topology = { somename = { type =...

or maybe something with tags is quite nice: ``` topology = { "sometagname" = { type = "mirror"; }; "cache" = { type = "cache"; }; "mirror" = { type...

what happens if a partition would be in the mirror and in the cache memberlist? is this something we want to catch or is this ok?

vdev instead of topology sounds like a good idea. I think we should stay very close to zfs terms so people are not confused by new words/concepts we introduce. about...

Hmm sadly I do not use home-manager. Not sure if they even support vm tests?

we could move the logic for adding zfsutil to the mountLine into an extraOption you could disable of the inherited datasets? maybe that settings can be done on zpool leven...

``` ... partitions = { boot = { type = "EF00"; size = "500M"; content = { type = "filesystem"; format = "vfat"; mountOptions = [ "umask=0077" ]; mountpoint =...

doing it via fileSystems is the expected way. Not sure if we want to replicate all fileSystems options in disko?

> * Does `flags = ["bios_grub"];` directly map to `type = "EF02";`? yes > * For blueberry host (first link), I have ESP partition starting at 1MiB and ending at...