m...@netbsd.org writes: > when asking for reviews on diffs, please consider having them in an easy > to view format, rather than tar files. > > Having a 'zfs' script to load a module sounds wrong. We have module > autoloading for this purpose.
Thanks for the comments... Ya, there are two purposes to the variable, one to make sure that the module loads early and the second for determining the desire to mount ZFS data sets in the mostly normal manor. If you have a corrupt ZFS cache, for example, you may want to not do the second one. The module has to load before zvols will show up and if that is ALL you were doing, I don't think anything else will prompt the loading of the module. That is, your /dev/zvol/* tree would not be there unless you execute the zfs (and probably the zpool) command prior to trying to use your devices (I think that it is the opening and use of /dev/zfs that does prompt the module load, but that isn't needed for pure zvol access). In addition, it is possible to put a FFS (or anything) in a zvol and use it in /etc/fstab, and the device would have to exist in that case too (technically the devices would still exist if you have used them once, but the module supporting them would not be present). I know that just trying to access /dev/zvol/* does not load the module. Hence the variable to prime the pump and get the module loaded early in the boot sequence. Off hand I do not know of any other way to get the desired behavior currently. Of course, in the root-filesystem-on-ZFS case this would not be needed (the module would have to be there already). In most of the ways that seem important the proposed behavior is not any different from what is done with LVM or raidframe currently. The zfs rc.d script may end up doing more in the future, like zpool import and the like. Make sense?? -- Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org
