Check if HDF5 "file" is a DAOS object

[brtnfld]

PR to skip the POXIS calls used in reading magic number. These POSIX calls can not be used for a DAOS object.

Intel DAOS team feedback is requested as we might be able to remove the HDF5 calls.

This solution assumes Unified Namespace and getfattr is available.

[brtnfld]

We might refrain from using getfattr if we modify H5Fis_accessible to return the VOL access type instead. Investigating.

[DennisHeimbigner]

I do not think this code is in the proper location. I think it should be part of the later file reading checks.

[brtnfld]

I do not think this code is in the proper location. I think it should be part of the later file reading checks.

I think it has to be before phase 7 because that looks like the first place you start to read the magic number. Where do you suggest?

[brtnfld]

I do not think this code is in the proper location. I think it should be part of the later file reading checks.

Wouldn't it be better to directly call getxattr(2) from sys/xattr.h here instead of calling a command which has to be in the path (sure, it is very likely the case) and could potentially do something else than returning file attributes? In the end, getfattr does same call to retrieve the attributes.... at least on a CentOS 7 installation.

Yes, that would be better.

[DennisHeimbigner]

FYI, I am working on this again.

[DennisHeimbigner]

If there is some way to modify this to avoid using popen, it would be appreciated.

[brtnfld]

Let me see what I can do, the eventual plan is to have H5Fis_accessible return if it is a DAOS container.

[edwardhartnett]

At the EGU I learned of some large data producers wanting to use DAOS for some of their very large data sets. I think it would be great of netCDF handled DAOS better.

I don't think this should hold up the long-awaited 4.9.0 release, but it would be great if this could be figured out for the 4.9.1 release...

[DennisHeimbigner]

To date, we have no solution.

[edwardhartnett]

@WardF can we get this merged? I'd love to test it, and I think it's an important feature. I note that it's scheduled for the 4.9.1 release, so if we can get it in I can test it in the next release candidate...

[brtnfld]

Here is the response I received from Intel:

You can use the extended attribute, check for its existence: /** extended attribute name that will container the UNS info */ #define DUNS_XATTR_NAME "user.daos"

Ideally you would use that macro, or the duns and call duns_resolve_path(), but you can’t do that I assume in this case since you would need to build netcdf with daos, right? You can just call lgetxattr on the path with that name and I would think it should be OK. If we change the actual name, one would need to update netCDF but I don’t see that happening.