accessing /dev/zfs is dependent on loading the zfs module which may take some time for udev to do it's work to create /dev/zfs. However, ZFS does allow this to be tweaked with the ZFS_MODULE_TIMEOUT environment variable:
From lib/libzfs/libzfs_util.c, libzfs_load_module:
/*
* Device creation by udev is asynchronous and waiting may be
* required. Busy wait for 10ms and then fall back to polling every
* 10ms for the allowed timeout (default 10s, max 10m). This is
* done to optimize for the common case where the device is
* immediately available and to avoid penalizing the possible
* case where udev is slow or unable to create the device.
*/
timeout_str = getenv("ZFS_MODULE_TIMEOUT");
...
so export ZFS_MODULE_TIMEOUT=0 may be a useful workaround for the moment. I wonder if that could be set automagically to zero lxc environment rather than hacking around zfs to detect if it is in a lxc container. The former does seem the best way forward.
accessing /dev/zfs is dependent on loading the zfs module which may take some time for udev to do it's work to create /dev/zfs. However, ZFS does allow this to be tweaked with the ZFS_MODULE_TIMEOUT environment variable:
From lib/libzfs/ libzfs_ util.c, libzfs_load_module:
/*
* Device creation by udev is asynchronous and waiting may be
* required. Busy wait for 10ms and then fall back to polling every
* 10ms for the allowed timeout (default 10s, max 10m). This is
* done to optimize for the common case where the device is
* immediately available and to avoid penalizing the possible
* case where udev is slow or unable to create the device.
*/
timeout_str = getenv( "ZFS_MODULE_ TIMEOUT" );
...
so export ZFS_MODULE_ TIMEOUT= 0 may be a useful workaround for the moment. I wonder if that could be set automagically to zero lxc environment rather than hacking around zfs to detect if it is in a lxc container. The former does seem the best way forward.