Hi, Just to remind that as PR1220 landed, now the “nr_xs_helpers” means the total number of helpers for the whole daos io server (previously it means #helpers per VOS target). It should only

I’ve landed a patch that should address this issue. From: daos@daos.groups.io [mailto:daos@daos.groups.io]On Behalf Of Olivier, Jeffrey V Sent: Wednesday, February 5, 2020 12:30 PM To:

Hi Bill, I’m able to reproduce the issue. Now it’s just a matter of figuring out why it is happening. I will file a ticket on it. Thanks, Jeff From: daos@daos.groups.io

Hi Colin, In the future the client will connect to the management service that (already today) maintains a key-value store mapping a pool UUID key to the essential pool information (of type struct

Hi Ken, Thanks for the info. Given just a Pool’s UUID, the client library (in the future) has to call each rank/daos_server until it hits 1 that is the Pool’s service replica? I assume the

Hello Colin, Here is a summary: It is currently the application’s responsibility to remember this initial list of service replica ranks. The dmg utility has a command “system list-pools”

Thanks for the reply Jeff. I do not have libfabric-devel installed. I am installing from master. The command I ran is: docker build -t daos -f Dockerfile.centos.7

Hi, The create pool api returns the pool service list. This list is passed in to the pool connect. Is it the application responsibility to remember this list? Or can you get the list given the

Hi Bill, Can you inform what version of daos you are using? Is it latest master? Also, do you have libfabric-devel package installed (DAOS doesn’t need this package to be installed). Also,

Hi there. I’m attempting to do an install into a Docker container running on top of CentOS 7 host. Close to the end of the process, I get the errors below and the install process aborts. Can someone

https://wiki.hpdd.intel.com/display/DC/Roadmap kevin ________________________________________ Sent: Wednesday, January 29, 2020 8:31 AM To: daos@daos.groups.io Subject: [daos] Is there a DOAS public

Hello Daos group id, I’ve been searching around on the github and can’t find the public roadmap details as referenced in the DAOS

Hello, This is a known issue. Ideally, SWIM suppose to detect these two dead servers, then DAOS should delete these servers from the system map, then MSR can skip these dead servers for pool

I have run into an infinite-loop problem with daos_test. Is this already a known problem? If not, I’m willing to open a Jira on it, but I’d like some input first on how the code is intended to

Thanks for info Kevan, We will update it locally and once it passes internal testing we will make build.config update ~~Alex. From: daos@daos.groups.io <daos@daos.groups.io>On Behalf Of

All, There is a bug in the version of ofi that CaRT is picking up in its build.config file. A new pthread was added in verbs;ofi_rm that handles unmap memory events so that the NIC can be

All, This is to report back on the infiniband failures seen in my original email below. The bottom line is, if a DAOS client is using ‘verbs;ofi_rxm’ as the fabric transport, and if there

Patrick, I tried removing all specification of the working directory, socket file, and log file from the agent and server, these things then being placed in /var/run/daos_agent/server, same

Based on the gRPC failure in the previous email the agent is functioning properly. It is saying that there is no server listening on localhost:10001 to receive the getAttachInfo call being made by the

Hi Shengyu Good to hear that cart/mercury issue is resolved. In general to avoid those issues it is best to remove _build_external/install if daos/utils/build.config changes as it would indicate