| 9 Nov 2022 |
 @elvishjerricco:matrix.org | and have udev rules that keeps that info up to date | 06:34:12 |
| @elvishjerricco:matrix.org | well and the initrd would still just hard code what pool it wants or something like that | 06:34:33 |
| @elvishjerricco:matrix.org | and use udev rules to wait for that pool to be ready | 06:34:43 |
 @uep:matrix.org | I mean it's basically a systemd generator for imports, similar to the one there now for mounts | 06:34:47 |
| @elvishjerricco:matrix.org | it would be if you knew the devices | 06:35:04 |
| @elvishjerricco:matrix.org | but you don't, and shouldn't | 06:35:07 |
| @uep:matrix.org | but it has to use data from the previous boot, which is of course fragile when you rebooted to change things | 06:35:21 |
| @uep:matrix.org | exactly | 06:35:27 |
| @elvishjerricco:matrix.org | that's why you want udev rules that update some metadata info | 06:35:40 |
| @uep:matrix.org | there are two basic ways to do it: wait till everything's settled then probe once, or probe every time a new disk appears until something's importable | 06:36:24 |
| @elvishjerricco:matrix.org | not exactly | 06:37:03 |
| @uep:matrix.org | which is probably going to take longer, especially for lots of spinning disks, the lookup can be slow | 06:37:08 |
| @uep:matrix.org | well 3, but the third uses cached info from previous boot, with the issues as noted above | 06:37:48 |
| @elvishjerricco:matrix.org | You don't have to like... run zpool import to check every time a disk attaches. ZFS should ship with a tool that can read the labels and know what disks are necessary. Then there can just be a rule that fires when the last disk appears, and it says "hey pool FOO is available" | 06:37:56 |
| @uep:matrix.org | * there are two basic ways to do it as pure discovery: wait till everything's settled then probe once, or probe every time a new disk appears until something's importable | 06:38:13 |
| @uep:matrix.org | that's roughly what I outlined above, yeah | 06:39:52 |
| @uep:matrix.org | but that event may not fire; a disk might be missing. the pool can still be importable (degraded). So you wind up having both this, and the wait anyway | 06:40:54 |
| @elvishjerricco:matrix.org | Yea, I think you'd want it to fire for each state change. "It's degraded." "It's available" | 06:41:17 |
| @elvishjerricco:matrix.org | and then the user can decide whether to try a degraded import | 06:41:26 |
| @uep:matrix.org | broadly speaking not really worth it I think | 06:41:28 |
| @uep:matrix.org | Or rather, effort better spent into looking into why 9s of waiting is needed even after all devices have appeared. | 06:42:12 |
| @uep:matrix.org | but even then, meh | 06:42:23 |
| @uep:matrix.org | fwiw, on my laptop there is no "udev settling time" in old stage1, and the prompt is almost instant. About to try it with systemd stage 1 too | 06:43:43 |
| @elvishjerricco:matrix.org | well old initrd definitely uses udev settle | 06:44:10 |
| @elvishjerricco:matrix.org | https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/boot/stage-1-init.sh#L259 | 06:44:32 |
| @elvishjerricco:matrix.org | ZFS stuff doesn't happen until after that | 06:44:42 |
| @uep:matrix.org | ok, no messages about it, at least, and no delay | 06:45:12 |
| @elvishjerricco:matrix.org | Yea I'd like to know what that's about... | 06:45:35 |
| @elvishjerricco:matrix.org | Maybe we just have too many udev rules in stage 1? | 06:45:44 |
