Colin,

I’m referring to the “Unified Name Space” feature or workflow that DAOS supports, in essence this is managed through the setting or a extended attribute “user.daos” on entries in the filesystem.  Applications with are DAOS aware will check for this attribute and consider such a file or directory as an indication that the container references in the extended attribute value should be accessed in lieu of the file.  This is handled through libduns, but it used by dfuse, dfs and mpiio drivers amongst others.

A typical use-case might be for the user to create a container, then have MPIIO write into it using the native DAOS api, but have the location/path/ownership handled though the filesystem, so the user might call “daos container create –path <path>” which would create a container, create a directory at <path>, set the extended attribute, then have their application access <path> via MPIIO which would automatically know this was a container and write directedly to DAOS.

The nomenclature is still in a state of flux, but generally unified namespace is the idea of being able to jump between containers transparently using userspace tools, and entry point is any special file/directory that has this extended attribute set.

This is also used in dfuse itself to link between pools, so you can start dfuse on <dfuse_root>, then run container create –path <dfuse_root>/new_dir which would create a new container that could be seamlessly accessed via the new directory.

What has changed recently is that if you run “dfuse –mount-point <path>” without specifying a pool or container then dfuse will check if the intended mount point is already a UNS entry point and if it is will use the pool/container uuids from there.  This is handled via the duns_resolve_path() function, which used to log a error if the path was not a entry point, but I thought I’d downgraded the message from error to info when I made the dfuse change.  This is the specific commit in question https://github.com/daos-stack/daos/commit/203e22ef6cf808f84f8f97965fe12f376c819daf  Either way the message should not be fatal as it’ll revert back to the old behaviour in the case where the extended attribute is not set.

Ashley,

Hi,

Can you provide more information with regards to “special UNS file”?

Thanks.

Colin

Could you send me the command line you’re using and the error message?  It would help to run in foreground mode to diagnose this.  We recently added a check for the mount point to be a special UNS file (by checking for a specific extended attribute) so there may be warnings given if this isn’t the case and that shouldn’t cause failure, except if you’re providing a pool UUID and the path is a UNS entry point.

Ashley Pittman.

---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.