https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-4606 Lustre <p>Lustre hard codes libzfs.so.1 in mount_utils_zfs.c<br/> ZoL git tree (after v0.6.2 tag) has bumped the so version to 2:0:0 so <br/> libzfs is now libzfs.so.2.</p> <p>This breaks user space utilities.<br/> Linking libzfs.so.2.0.0 to libzfs.so.1 works so there doesn't seem to be <br/> any ABI breakage.</p> RHEL 6.x Lustre 2.4.2 with ZFS LU-4606

Lustre hard codes libzfs.so.1 in lustre/utils/mount_utils_zfs.c

Bug Major Resolved Fixed Nathaniel Clark Anthony Alba zfs Mon, 10 Feb 2014 15:47:51 +0000 Mon, 3 Nov 2014 18:44:53 +0000 Wed, 21 May 2014 14:16:44 +0000 Lustre 2.5.0 Lustre 2.6.0 Lustre 2.4.2 Lustre 2.6.0 Lustre 2.5.3 0 9 <p>I do have a patch related to this <a href="http://review.whamcloud.com/#/c/8979/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/8979/</a></p> <p>This will be updated when the next stable release of zfs/spl happens.</p> <p>Its better to add configure time check for libzfs version and link it directly to mkfs.lustre instead of dlopening it</p> <p>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.</p> <p>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.</p> <p>See ORI-425: <a href="http://review.whamcloud.com/1740" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/1740</a> and <a href="http://review.whamcloud.com/1742" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/1742</a></p> <p>It seemed that the dynamic linker would only try to resolve symbols when they're first used. From ld.so(8):<br/> LD_BIND_NOW<br/> If present, causes the dynamic linker to resolve all symbols at program startup instead of when they are first referenced.</p> <p>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.</p> <p>Ran with lastest masters of lustre, zfs and spl <a href="http://review.whamcloud.com/#/c/8979/6" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/8979/6</a> but ran into ZFS bug <a href="https://github.com/zfsonlinux/zfs/issues/1891" class="external-link" target="_blank" rel="nofollow noopener">1891</a> in sanity/65ia</p> <p>The ZFS bug need not hold up fixing this bug correctly.</p> <p>Does sanity/65ia consistently reproduce this issue?</p> <p>LLNL completely agrees with the previous commenters in this ticket that argue for the removal of the hardcoded zfs library versions in dlopen() calls in lustre. I commented to that effect in my review of patch <a href="http://review.whamcloud.com/8979" class="external-link" target="_blank" rel="nofollow noopener">8697</a>.</p> <p>The issue was raised that rpm will add a dependency on zfs if you compile with ZFS support. Frankly, I don't see the problem. If you don't want a dependency on zfs, don't compile against zfs. Same with ldiskfs.</p> <p>But ok, fine, I'll play along. So you want to make both OSD rpms available, but neither required. Then obviously we need to have any direct dependencies on the contents of those OSD rpms contained in those OSD rpms, not present in more general shared RPMs.</p> <p>So how about fixing that issue? Modularize the mount command. Each OSD rpm offers a dynamically loadable component for the main mount command. The mount command can then load the osd-specific shared library as needed, and only that osd shared library has dependencies on the backend filesystem. At rpm build time, the zfs osd rpm would have the dependencies on zfs, and the ldiskfs osd rpm would have the dependencies on ldiskfs. No leakage of dependencies into the more general rpms.</p> <p>I'm just throwing this out off the top of my head. Other options are possible.</p> <p>Granted, our current hard-code-the-library-string strategy was easy the first time, but it also half-assed and causing maintainance problems. Lets take the time to do it right this time around.</p> <p>This splits zfs functionality out of mount/mkfs into a loadable module and puts that module in lustre-osd-zfs</p> <p><a href="http://review.whamcloud.com/10193" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/10193</a></p> <p>Patch landed to master, Opened <a href="https://jira.whamcloud.com/browse/LU-5096" title="Linker cannot find custom libzfs location like it can with header files" class="issue-link" data-issue-key="LU-5096"><del>LU-5096</del></a> to address Brian's issues with custom libzfs location that I missed.</p> Duplicate LU-5060 Related LU-4944 LU-2976 LU-5091 LU-5102 LU-5851 LU-5501 LU-5096 LU-5643 Development Epic/Theme ZFS Rank 1|hzwep3: Rank (Obsolete) 12600 Severity