If you're running zfs tools in a container setting the timeout to 0 will likely be helpful. The device node will never appear in the containers /dev since a) it's a tmpfs and b) even if it were a devtmpfs it wouldn't help since devtmpfs isn't namespaced. (In fact udevd will even ignore any device event inside an unprivileged container since it's sent with INVALID_{G,U}ID. I have kernel patches to handle this and a bunch of other quirks that are up for merging.) For unpriv containers any device that you somehow create by talking to /dev/zfs (e.g. by having LXD create a device node for the container) will never show up in the container. It will always show up in the hosts devtmpfs.
On the host setting it to 0 should also not have a negative effect since the modprobe should a) cause devtmpfs to create the device node *before* sending a uevent and b) zfs userspace will likely wait for udevd to settle aka setup symlinks and persistent device naming. The timeout logic only makes sense for old udevd implementations that do create device nodes and might do so in a delayed manner. But better to test. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1760173 Title: zfs, zpool commands hangs for 10 seconds without a /dev/zfs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1760173/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs