| 9 Nov 2022 |
 @elvishjerricco:matrix.org | uep: Yea, it's all good. As expected | 06:21:57 |
 @uep:matrix.org | 15s between the start and stop. More than it seemed like at the time tbh | 06:22:10 |
| @elvishjerricco:matrix.org | oh seriously? wtf | 06:22:20 |
| @elvishjerricco:matrix.org | that's a really long time | 06:22:23 |
| @uep:matrix.org | mostly usb and nvme probing from the kernel. | 06:23:06 |
| @uep:matrix.org | and then 9s of nothing before the "finished" above | 06:23:51 |
| @elvishjerricco:matrix.org | On my system there's only 3s between Starting Wait for udev To Complete Device Initialization and Finished Wait for udev To Complete Device Initialization | 06:23:57 |
| @uep:matrix.org | Nov 09 17:06:16 localhost kernel: logitech-hidpp-device 0003:046D:4082.0007: input,hidraw4: USB HID v1.11 Keyboard [Logitech MX Master 3] on usb-0000:05:00.3-2.4/input2:2
Nov 09 17:06:25 localhost systemd[1]: Finished Wait for udev To Complete Device Initialization.
| 06:24:39 |
| @elvishjerricco:matrix.org | geez, that's unfortunate | 06:24:50 |
| @uep:matrix.org | I'll try another box or too as well.. | 06:25:40 |
| @uep:matrix.org | but mostly NBD since it stops and waits for a passwd anyway | 06:25:52 |
| @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 |
