Is the LVM dependency intentional?

[sterlingjensen]

I was working through the test scripts, cutting down the number of unnecessary execve calls, when I noticed a hardcoded path to dmsetup in scripts/zfs-tests.sh. I've always gotten more failures on my stripped down gentoo build, and just attributed it to the state of our test framework, but in this case we've got an undocumented (?) dependency on LVM. I've always avoided it, and I don't understand why anyone would want to mix it with ZFS. I started replacing the dmsetup functionality with what we already have available, but then I began wondering if everybody else was assuming that device-mapper was installed on every linux machine - and I'm the crazy one. Anybody got the scoop?

[behlendorf]

I'm pretty sure this functionality isn't used anymore, we definitely don't use it for any of our testing. It was added a long time ago as a way to facilitate testing with block devices (the loop device code in Linux used to have some problematic limits, but that's no longer the case). I wouldn't be at all opposed to removing dmsetup from the zfs-tests.sh script entirely.

[sterlingjensen]

Good to know, that'll certainly make the streamlining effort easier - portability-wise. After the low hanging fruit is taken care of (echo xx | sed 's/^x//' kinds of things), I was hoping to better take advantage of ksh specific features (like loadable precompiled builtins) to reduce boilerplate and test runtime. Obviously that would further commit the test framework to a ksh dependence (but also potentially relieve us of the python runner). I don't know if you planned on going another direction with the test framework, so I guess it would be best to find that out sooner than later.

[behlendorf]

Any improvements would be welcome. Due to the large number of tests we're already pretty effectively committed to the ksh dependency. It would take a substantial amount of work to change that, and thus far sticking with ksh hasn't been an issue. So I don't think it's likely we'd want to change it any time soon.