diff options
| author | Brian Behlendorf <[email protected]> | 2013-07-02 11:59:51 -0700 |
|---|---|---|
| committer | Brian Behlendorf <[email protected]> | 2013-07-03 09:24:38 -0700 |
| commit | 91604b298c24c84fe03bc6c028abb961ca3e6fcf (patch) | |
| tree | bff83bc3f42c2fc185ff20a4d9002bdc76d71773 /module/zfs | |
| parent | 2a3871d4bcc65dff7be4c9b55cb863421ddc8c3a (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 'module/zfs')
| -rw-r--r-- | module/zfs/zvol.c | 2 |
1 files changed, 0 insertions, 2 deletions
diff --git a/module/zfs/zvol.c b/module/zfs/zvol.c index 97b65c815..e35c91bc1 100644 --- a/module/zfs/zvol.c +++ b/module/zfs/zvol.c @@ -1582,8 +1582,6 @@ zvol_init(void) blk_register_region(MKDEV(zvol_major, 0), 1UL << MINORBITS, THIS_MODULE, zvol_probe, NULL, NULL); - (void) zvol_create_minors(NULL); - return (0); out2: |