libzfs.h in tree location vs. rpm install location

[prakashsurya]

Hey Brian,

The libzfs.h file is found in the include directory, but it is installed in include/libzfs when installing the built RPM. Should the file be moved into include/libzfs in the build directory?

This discrepancy prevents the Lustre orion branch from building against a make'd ZFS build directory, as the Lustre sources #include <libzfs/libzfs.h>

Should this be fixed in ZFS? Or should Lustre instead #include <libzfs.h> and setup it's include path correctly depending on if it's using an RPM install or local build directory of ZFS?

[behlendorf]

Thanks for filing this. I've been meaning to open an issue for this known problem for a while now. Your exactly right about the problem, but the solution is a little more complicated than it first appears.

I've given this some thought and my inclination is to update the zfs source to match the install paths which are more correct for a Linux system. However, if we do that we'll need to update the #include's in most of the zfs source files and headers to reference the new location. This will need to be done in the spl and zfs code and may result in some conflicts with existing Linux headers. It will also move us father away from the upstream zfs source.

Now at the moment I think this is all worth doing, however it's not a small change. The workaround of course is to just use the spl/zfs rpm packages when building Lustre which is frankly the right thing to do anyway. It's just a little annoying for development.

[prakashsurya]

Yea, installing the RPM is what I did to get around the issue.

And moving further away from upstream ZFS is what I was afraid of.. But if you think modifying the ZFS and SPL side of things is correct, I can make the patch and push it up to you. What sort of "conflicts with existing Linux headers" do you foresee? I had originally thought changing the ZFS and SPL #include directives to match the new location would suffice. Is that not the case?

[behlendorf]

I don't have a good example of a conflict, but I've got a hunch we'll find something which causes trouble. Many of the headers in the spl do have exactly the same names as their linux counterparts. These changes need to work for both the user space and kernel space build so it's a little more complicated than it first appears. If I were you I'd skip this for now and perhaps take a look at the slow unlink times of a large file through the posix layer.

[behlendorf]

Lustre has been updated accordingly.