Re: Legacy ZFS mounts

[Brad Spencer <brad%anduin.eldar.org@localhost>]

maya%NetBSD.org@localhost 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 - brad%anduin.eldar.org@localhost - KC8VKS - http://anduin.eldar.org