2 Commits

Author	SHA1	Message	Date
Brian Behlendorf	91604b298c	Open pools asynchronously after module load ... One of the side effects of calling zvol_create_minors() in zvol_init() is that all pools listed in the cache file will be opened. Depending on the state and contents of your pool this operation can take a considerable length of time. Doing this at load time is undesirable because the kernel is holding a global module lock. This prevents other modules from loading and can serialize an otherwise parallel boot process. Doing this after module inititialization also reduces the chances of accidentally introducing a race during module init. To ensure that /dev/zvol/<pool>/<dataset> devices are still automatically created after the module load completes a udev rules has been added. When udev notices that the /dev/zfs device has been create the 'zpool list' command will be run. This then will cause all the pools listed in the zpool.cache file to be opened. Because this process in now driven asynchronously by udev there is the risk of problems in downstream distributions. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue #756 Issue #1020 Issue #1234	2013-07-03 09:24:38 -07:00
Kyle Fuller	146cde8f4a	Move 90-zfs udev rule from dracut to udev/rules.d ... This rule does not need to be dracut specific. Automatically loading the zfs module stack when a zfs device is detected is usually desirable. My only concern is that this might cause trouble for large pools where we don't want to automatically import the pool until all the disks are available. However, we'll cross that bridge when we come to it. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>	2011-08-19 16:26:13 -07:00