| 9 Nov 2022 |
 @elvishjerricco:matrix.org | yea it'd be really nice to have better udev support from zfs | 06:26:13 |
 @uep:matrix.org | nothing zfs (that I can spot in the logs at least) happens before then, other than the modules getting loaded | 06:30:31 |
| @elvishjerricco:matrix.org | right, that's the problem :) | 06:30:43 |
| @elvishjerricco:matrix.org | ZFS doesn't know how to know when a pool is ready to import | 06:30:51 |
| @elvishjerricco:matrix.org | so it just waits for all udev stuff to be done | 06:30:58 |
| @elvishjerricco:matrix.org | even though that's way more than necessary | 06:31:05 |
| @uep:matrix.org | oh right | 06:31:06 |
| @uep:matrix.org | yeh, fair | 06:31:14 |
| @uep:matrix.org | though at this point you don't really know what pools / devices you're waiting for, you could have an event that fires when all the device members of a pool have appeared by looking at the labels, but you don't actually want to import them anyway | 06:33:11 |
| @uep:matrix.org | (they might be busy on another system with multi-attach, among other wrinkles) | 06:33:34 |
| @elvishjerricco:matrix.org | Yea that's sort of the direction a fix would go in | 06:33:34 |
| @elvishjerricco:matrix.org | just create some virtual info that tracks what pools have been noticed on devices, along with how import-able it is | 06:34:04 |
| @uep:matrix.org | to know which you might want to import, you'd need to basically parse or bundle in the cache file into the initrd. | 06:34:09 |
| @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 |
