[LU-4606] Lustre hard codes libzfs.so.1 in lustre/utils/mount_utils_zfs.c

• Type: Bug
• Resolution: Fixed
• Priority: Major
• Fix Version/s: Lustre 2.6.0, Lustre 2.5.3
• Affects Version/s: Lustre 2.5.0, Lustre 2.6.0, Lustre 2.4.2
• Labels: zfs
• Environment: RHEL 6.x Lustre 2.4.2 with ZFS

Epic/Theme

ZFS

• Severity: 3
• Assignee: Nathaniel Clark
• Reporter: Anthony Alba

Description

Lustre hard codes libzfs.so.1 in mount_utils_zfs.c
ZoL git tree (after v0.6.2 tag) has bumped the so version to 2:0:0 so
libzfs is now libzfs.so.2.

This breaks user space utilities.
Linking libzfs.so.2.0.0 to libzfs.so.1 works so there doesn't seem to be
any ABI breakage.

Issue Links

• duplicates: LU-5060 mkfs.lustre --backfstype=zfs fails to execute due to fix library name libzfs.so.1
• is related to: LU-5091 LU-4606 breaks --with-zfs-devel option
• is related to: LU-5102 Loading plugin for a given mount_type from ${pkglibdir}/mount_osd_FSTYPE.so" brings problem to local testing.
• is related to: LU-5851 Handle LU-4606 packaging changes for Lustre Server DKMS RPM
• is related to: LU-5501 new e2fsprogs causes llverfs build failures
• is related to: LU-5096 Linker cannot find custom libzfs location like it can with header files
• is related to: LU-5643 Flubbed merging of two patches in change I1d69b64eec1589f63e24f20cc624778a4be2ec60
• is related to: LU-4944 build fails with latest zfs source
• is related to: LU-2976 ZFS upstream sonames are versioned

Comments

[Christopher Morrone (Inactive)]

The ZFS bug need not hold up fixing this bug correctly.

[Nathaniel Clark]

Ran with lastest masters of lustre, zfs and spl http://review.whamcloud.com/#/c/8979/6 but ran into ZFS bug 1891 in sanity/65ia

[Isaac Huang (Inactive)]

It seemed that the dynamic linker would only try to resolve symbols when they're first used. From ld.so(8):
LD_BIND_NOW
If present, causes the dynamic linker to resolve all symbols at program startup instead of when they are first referenced.

If true, then it might work if we just delay that zfs_init() call until when the 1st real zfs operation is needed, e.g. in zfs_make_lustre(). Then we'd be able to get rid of the dlopen() without causing headache to ldiskfs systems. I'm no expert on the dynamic linker, but it seems worthwhile to give it a shot.

[Andreas Dilger]

The reason that mkfs.lustre is using dlopen() instead of linking to the ZFS library directly is so that the same user tools can be used on systems with or without ZFS packages installed.

See ORI-425: http://review.whamcloud.com/1740 and http://review.whamcloud.com/1742

[Richard Yao]

ZFSOnLinux imported a change to its internal library API from Illumos, which required a SONAME bump. It would be advisable to evaluate a switch to the new libzfs_core library, which is meant to provide a public library API with a stable interface.

[Alexey Shvetsov (Inactive)]

Its better to add configure time check for libzfs version and link it directly to mkfs.lustre instead of dlopening it

[Nathaniel Clark]

I do have a patch related to this http://review.whamcloud.com/#/c/8979/

This will be updated when the next stable release of zfs/spl happens.