Johann Lombardi invites you to join this Webex meeting. Meeting number (access code): 130 258 2165

On Thu, Sep 17, 2020 at 12:56 AM, Lombardi, Johann wrote: adrfam:IPv4 traddr:10.9.1.118 trsvcid:4420 subnqn:test I've tried to change daos_nvme.conf in runtime of daos server and before starting due

This specific issue is different appears to be at the dfuse/fuse kernel module level. I note you’re using a newer fuse driver than I am (7.31 vs 7.23) and also a newer libfuse3 as evidenced by the

This case is different, the mount point here has not been used to create a container so dfuse is attempting to use the pool and container on the command line. The error reported is a DAOS error

Hi, This is the same issue as Gert hit last week, specifically that you’re providing the pool/container UUIDs twice to dfuse, one via the path and once on the command line. The fix in this case

I'm experiencing (most likely) the same issue since a week or more on the master branch. I reproduced it on today's master branch on Ubuntu 20.04. Verified a few days ago on Centos

Thanks for the response, I tried again with: dfuse --mountpoint=/home/daos/container/ --svc=0 --pool=[pool_id] --container=[container_id] --foreground This led to the following

Hello! Could you try using the mountpoint different from container path? Afaik, the path given to `daos cont create` is used as an alias to the container. Yunjae

Hello! I am trying to use dfuse to create a POSIX-enabled mount. My container is created thusly: daos cont create --pool=[pool_id] --svc=0 --type=POSIX --path=/tmp/mycontainer I then try to mount

The issue is gone after adopting Kennth’s suggestion to set “crt_timeout: 1200” in global area of daos_server.yml instead of under “servers/env_vars”. @Cain, Kenneth C, thanks!

Hello Jaifu, Can you try to set the server RPC timeout by using the daos_server.yml file crt_timeout setting (and not using the env_vars section with the CRT_TIMEOUT variable)? See

The most recent worked commit I can track is 681b827527a0587d8496d3adbbd77a175370766c (Feb 28). From: Zhang, Jiafu Sent: Tuesday, September 29, 2020 8:25 AM To: daos@daos.groups.io Subject: RE:

I just recalled that I re-opened the ticket on Aug 10. The issue has been existed for long time. Please see detailed info in the ticket. From: daos@daos.groups.io <daos@daos.groups.io> On Behalf

Hi Jiafu, What was the previous commit that you know of that works in your setup? Thanks, ~~Alex. From: daos@daos.groups.io <daos@daos.groups.io> On Behalf OfZhang, Jiafu Sent: Monday,

Thanks for the quick reply, Patrick. I was also wondering how small the I/O size should be to go to SCM rather than NVMe. I'll test performances following your advice. It helped me a lot.

Yunjae, The concept of an object being allocated in SCM or NVMe doesn't really apply in DAOS. If both SCM and NVMe are present, objects will use either one, based on i/o size. If the i/o size is <4K,

Is there any way to check if an object is allocated in SCM or NVMe? I installed DAOS in a simple server with Intel DCPMM and NVMe SSD, and I want to compare the I/O performance of the both two cases.

Hi Guys, I failed to create pool with recent master commits back to 6726e272e2a0e821c0676838c39a2b133a7e0612 (9th Sep). The error in terminal is, Pool-create command FAILED: pool create

Glad it helped. You might also want to remove /tmp/daos_server.log which is probably pretty big. As for getting even better performance, I would increase the block size to write more and maybe try

Johann thank you so much! I've set log_mask to err and i had 10x better performance even on one socket. Here is my results: POSIX: mpirun --allow-run-as-root -np 18 --bind-to socket ior -a POSIX -b 1G