The cart context of the normal process needs to be initialized so that it can communicate normally with the failed recovery process. Thank you for your reply！

Thanks for the clarification. Since the engine is killed and restarted in step 4, I am not sure to understand why network contexts would need to be reinitialized. Could you please create a jira ticket

Gǎnxiè nín de huīfù, nǐ de lǐjiě shì duì de. Dāngshí wǒmen zhíxíng de cāozuò shì: 1) Bá diào wǎngxiàn 2) shā diào wǎngxiàn duìyìng de jìnchéng 3) chóngxīn chārù

Hi there, IIUC, you are running into a bug where a DAOS engine is not able to rejoin the system / CART group if you “just” unplug & replug the network cable. You then noticed that you could

We tried the mercury demo and found that initializing hg can solve this OOG problem, and then analyzed the code of the cart， and found that the cart context applied a global context, and it is used

Hi there, The DAOS architecture won’t fundamentally change and the plan is to become more flexible in the configurations we support. We will continue to store metadata and data on different

DAOS continues to be a strategic part of the Intel software portfolio and we remain committed to supporting our customers and the DAOS community. In parallel, we are accelerating efforts that have

Intel recently announced that it will no longer provide 3D Xpoint DIMMs, so how will this affect DAOS?

DAOS team would like to announce the release of DAOS Version 2.0.3. This is a maintenance release containing bug fixes and improvements. The DAOS 2.0.3 release contains the following updates

Hi ，DAOS: I'm looking at the raft's code. func (r *Raft) run() { for { // Check if we are doing a shutdown select { case <-r.shutdownCh: // Clear the leader to prevent

After looking at the code I think I agree with this suggestion, otherwise the reqGroupUpdate(sync=false) call on src/control/server/server_utils.go L514 is ineffectual. Good catch! From:

Thanks, mjmac. I think the code case sync := <-svc.groupUpdateReqs: groupUpdateNeeded = true if sync { if err := svc.doGroupUpdate(parent, true); err != nil { svc.log.Errorf("sync

To be clear, once a group map update has been requested, it will happen within 500ms of the request. This is triggered by a timer, not by a join request. Every 500ms, the timer fires and a check

Thank you，mhmac！ So the reason for passing false is to allow for efficient batching of group updates. But is it OK that engines don't get the newest groupmap? Sometimes, there may be no engine

Hi Qui. I assume you are referring to this line of code:https://github.com/daos-stack/daos/blob/master/src/control/server/server_utils.go#L518 In this case, the false value indicates that the

Hi, DAOS, I found when daos_server received RASSwimRankDead, daos_server updated membership imediately, but it put a false in reqGroupUpdate, then it would not pass the new groupmap to daos_engine.

Hi there, Please find below the DAOS community newsletter for July 2022. A copy of this newsletter is available on thewiki. Past Events ISC’22 IXPUG (June 2nd at 9am CEST) DAOS Features

Yes, that’s the reservation I mentioned, and the NVMe reservation has been removed in master and 2.2. Thanks -Niu From: <daos@daos.groups.io> on behalf of "Tuffli, Chuck"

Apologies. I was wrong. The space drops with pool creation, not with container creation. Creating a pool # dmg pool create --ranks=0,3 --size=500G kiddie Creating DAOS pool with automatic storage

Could you double check if creating container would cause NVMe free space dropping? If it’s true, please open a ticket for further investigation. I can’t think of why container creation could