The common.sh script assumed that it was either being run from
in-tree or was installed under /usr/libexec/zfs. If this was
not the case, because of say the default --prefix=/usr/local,
then the paths would be wrong. To fix this common.sh is now
generated from common.sh.in with the correct path information
provided at configure time.
Devices were only being created at module load time or when a
dataset was created. Similiar devices were not always being
removed at all the correct times. This patch updates all the
places where devices should either be created or removed. I'm
reasonably sure I got them all but if theres a case I missed
we can catch it with a follow up patch.
module load/unload
zfs create/remove
zpool import/export
zpool destroy
This patch also adds a simple regression test to zconfig.sh
to ensure zpool import/export is basically working properly.
This test specifically checks that devices are created
properly, removed after export, created after import, and
removed as a consequence of a zpool destroy.
Due to now resolved bug in the SPL you would need to explicitly
import you zpools after module load. Now that is no longer the case.
If a cache file is found your pool will be automatically loaded and
available so I'm removing the explicit imports from the test case.
Pass an alternate location via module option for the zpool.cache file
used by the kernel. This allows us to write in-tree tests which do
not modify any out-of-tree files we do not own. This is just standard
good behavior for any test suite.
Additionally, refine the existing test case to explicity use the cache
file when looking for pools to import. And add a second test cache
which is forced to probe the disks for available pools to import.
This is an initial script for validation of zfs/zpool configuration.
For now there is only one test here to ensure that /etc/zfs/zpool.cache
is being updated properly from the kernel module. Additional tests
should be added, I believe Richardo said there was an existing test
suite out there which validated the behavior of many zpool/zfs commands.
It would be nice to add that as appropriate.
Brian Behlendorf
Ricardo M. Correia