[LU-3903] build fails with latest zfs source Created: 07/Sep/13  Updated: 04/Nov/13  Resolved: 02/Oct/13

Status: Resolved
Project: Lustre
Component/s: None
Affects Version/s: Lustre 2.6.0
Fix Version/s: Lustre 2.5.0, Lustre 2.4.2

Type: Bug Priority: Blocker
Reporter: Bob Glossman (Inactive) Assignee: Nathaniel Clark
Resolution: Fixed Votes: 0
Labels: zfs

Issue Links:
Related
is related to LU-3678 Update zfs build version to 0.6.2 Resolved
Severity: 3
Rank (Obsolete): 10267

 Description   

I can no longer build lustre against the latest upstream zfs source pulled from the master branch of github.com/behlendorf/zfs.git. A recent commit has eliminated the internal API dsl_prop_set() used in osd-zfs code.

This is not currently a problem in our build and test framework where builds are done against an earlier, fixed, and frozen version of zfs source. It will become a problem the next time we sync up to the latest upstream zfs version.



 Comments   
Comment by Bob Glossman (Inactive) [ 09/Sep/13 ]

I note that the offending commit that changed the zfs API in an incompatible way went in after the 0.6.2 tag. We can build OK against the upstream zfs-0.6.2 version.

Comment by Jodi Levi (Inactive) [ 09/Sep/13 ]

Nathaniel,
Can you please look into this one?

Comment by Nathaniel Clark [ 09/Sep/13 ]

From what Bob told me via IM, the offending change is after the 0.6.2 tag, so this doesn't directly affect LU-3678.

Comment by Nathaniel Clark [ 12/Sep/13 ]

The change in ZFS is relatively minor, but needs a configure change in lustre to detect the difference.

ZFS change is 13fe019870c8779bf2f5b3ff731b512cf89133ef

Change needed in lustre is in lustre/osd-zfs/udmu.c in udmu_userprop_set_str() need to use dsl_prop_set_string() if it exists instead of dsl_prop_set().

Otherwise, code compiles without issue.

Comment by Nathaniel Clark [ 17/Sep/13 ]

http://review.whamcloud.com/7685

Comment by Peter Jones [ 02/Oct/13 ]

Landed for 2.5.0

Generated at Sat Feb 10 01:37:55 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.