[Debian Lenny] zfs: Unknown symbol lookup_bdev #1205
Comments
|
Dang, I would guess I am guilty here. As you point out, it is from #1131 . Although, when we checked lookup_bdev was available in 2.6. |
|
The problem is that while the function exists all the way back to at least 2.6.12. It wasn't until 2.6.27 that the function was made available to modules by adding the EXPORT_SYMBOL() call. I didn't notice this either when initially landing the patch and apparently nobody else did either for the last month. That probably says something about how many Debian Lenny users are left out there. It seems to me we have 2 options.
|
|
For the record, I don't care about Lenny :). I just happened to find this during testing, so I'm fine with dropping support. |
|
It would better to revert 6c28567 in favor of making vdev_uses_zvols return true unconditionally. The original patch made things work when a raw zvol is being used for ZFS, but if you put something between the zvol and ZFS, such as LVM, the original deadlock will still occur. |
|
@ryao Until someone comes up with a legitimate use case for the following layering I'm inclined not to spend time worrying about it. However, we could add the autoconf check to detect the missing symbol and just return true unconditionally since that would be safe. vdev |
|
@behlendorf a legitimate use case could be DRBD? |
|
@behlendorf There are virtual machines using ZFS on dm-crypt/luks: https://mthode.org/posts/2012/Dec/gentoo-hardened-zfs-rootfs-with-dm-cryptluks-updated-2012-12-12/ If something goes wrong in one of them, it would be useful to be able to import the pool on the host to do repairs. It is not possible to do that with the current code. The same reasoning applies to doing the installation on the host, which is also not possible with the current code. |
|
I just had an idea for an alternative way of handling this. We could check for the whole_disk flag. If whole_disk is 1 on all child vdevs and the immediate block device is not a zvol, then it is safe to do the parallel import. Otherwise, it is not. In addition, if there is only 1 vdev, it makes no sense to do the parallel import, so it can be avoided. I will take some time to write a patch based on this idea later today. It should handle all cases of interest gracefully. |
|
I probably should add that I have already taken the liberty of writing an autotools check for lookup_bdev in ryao/spl@2e24d25. |
|
@ryao Thanks for the 2.6.26 compatibility code, I can get it reviewed and merged to solve the immediate issue. Also the VM use case does seem like a legitimate reason to fix this. I like your idea about avoiding use the taskqs when |
|
We can revisit doing something clever in the future as an optimization. For now I've just resolved the build issue for 2.6.26 kernels which probably nobody noticed but Ned and I. 2b7ab9d Linux 2.6.26 compat, lookup_bdev() |
It's doubtful many people were impacted by this but commit 6c28567 accidentally broke ZFS builds for 2.6.26 and earlier kernels. This commit depends on the lookup_bdev() function which exists in 2.6.26 but wasn't exported until 2.6.27. The availability of the function isn't critical so a wrapper is introduced which returns ERR_PTR(-ENOTSUP) when the function isn't defined. This will have the effect of causing zvol_is_zvol() to always fail for 2.6.26 kernels. This in turn means vdevs will always get opened concurrently which is good for normal usage. This will only become an issue if your using a zvol as a vdev in another pool. In which case you really should be using a newer kernel anyway. Signed-off-by: Brian Behlendorf <[email protected]> Closes openzfs#1205
On Debian Lenny, Linux 2.6.26, the lookup_bdev symbol can not be resolved. I don't understand why; it's definitely available in the kernel.
Introduced by commit 6c28567
The text was updated successfully, but these errors were encountered: