cannot mount daos with the latest code on github
|
Wu Huijun
Hi guys, I used to be able to mount DAOS with dfuse. However, I failed to do the same with the latest DAOS code on GitHub. I got errors complaining the path is not in a unified DAOS namespace. Any ideas about this? Thanks! Cheers, Hector Wu |
|
|
|
Pittman, Ashley M
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.
From:
<daos@daos.groups.io> on behalf of Wu Huijun <huijunw91@...>
Hi guys, --------------------------------------------------------------------- This e-mail and any attachments may contain confidential material for |
|
|
|
Colin Ngam
Hi,
Can you provide more information with regards to “special UNS file”?
Thanks.
Colin
From: <daos@daos.groups.io> on behalf of "Pittman, Ashley M" <ashley.m.pittman@...>
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.
From:
<daos@daos.groups.io> on behalf of Wu Huijun <huijunw91@...>
Hi guys, --------------------------------------------------------------------- This e-mail and any attachments may contain confidential material for |
|
|
|
Wu Huijun
Hi Pitman and Colin, The problem was solved by put the mount point on a disk-based rather than memory-based file system. Do you know why this happened? Cheers, Hector Wu On Sat, Jun 6, 2020 at 5:07 AM Colin Ngam <colin.ngam@...> wrote:
|
|
|
|
Pittman, Ashley M
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,
From:
<daos@daos.groups.io> on behalf of Colin Ngam <colin.ngam@...>
Hi,
Can you provide more information with regards to “special UNS file”?
Thanks.
Colin
From:
<daos@daos.groups.io> on behalf of "Pittman, Ashley M" <ashley.m.pittman@...>
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.
From:
<daos@daos.groups.io> on behalf of Wu Huijun <huijunw91@...>
Hi guys, --------------------------------------------------------------------- This e-mail and any attachments may contain confidential material for --------------------------------------------------------------------- This e-mail and any attachments may contain confidential material for |
|
|
|
Pittman, Ashley M
From:
<daos@daos.groups.io> on behalf of Wu Huijun <huijunw91@...>
Hi Pitman and Colin,
The problem was solved by put the mount point on a disk-based rather than memory-based file system.
Do you know why this happened?
I don’t know why that would be. It’s possible that your memory-based filesystem doesn’t supported extended attributes which would cause a different log message to be recorded at a higher priority but wouldn’t affect the functionality, or it’s possible that there’s some mount options on that are different, I know there’s no-suid and no-exec options, but I’m not aware of any no-sub-mount-within-tree type of mount option that your memory based filesystem may be using.
Failures to mount fuse will be printed to stdout by libfuse itself and this would be the best clue as to the cause, in order to see these messages you need to run dfuse with the –foreground option, if you can do that and send us the message than you’re seeing we can investigate further.
Ashley. --------------------------------------------------------------------- This e-mail and any attachments may contain confidential material for |
|
|