aboutsummaryrefslogtreecommitdiffstats
path: root/rpm/generic/zfs.spec.in
diff options
context:
space:
mode:
authorBrian Behlendorf <[email protected]>2013-07-02 11:59:51 -0700
committerBrian Behlendorf <[email protected]>2013-07-03 09:24:38 -0700
commit91604b298c24c84fe03bc6c028abb961ca3e6fcf (patch)
treebff83bc3f42c2fc185ff20a4d9002bdc76d71773 /rpm/generic/zfs.spec.in
parent2a3871d4bcc65dff7be4c9b55cb863421ddc8c3a (diff)
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 <[email protected]> Issue #756 Issue #1020 Issue #1234
Diffstat (limited to 'rpm/generic/zfs.spec.in')
0 files changed, 0 insertions, 0 deletions