DAOS supports the conversion of handles local2global and global2local. What are implications if any, if each process just perform local connect or open? Pool/Container/Objects.
The major advantage of using the l2g, g2l is performance.
Doing a 1 per process call to connect / open is issuing an RPC to the server side, and pool / container operations are expensive.
Those functions are there to improve performance in cases where clients can communicate and share the handles vs all going to the server side. If clients can share those handles, we definitely encourage doing
that vs doing an independent pool connect or container open.
(note: similar functionality exists for dfs_mount)
Think of it as something like a file open. Middleware over parallel filesystems today try to improve performance of open by having 1 opener and sharing the open file handle to other peers (especially in an
MPI environment when you have a collective open, and that is if the PFS supports such a thing). PFS that do not have this feature often struggle performance wise in the open phase.
Thanks,
Mohamad
From: <daos@daos.groups.io> on behalf of Colin Ngam <colin.ngam@...> Reply-To: "daos@daos.groups.io" <daos@daos.groups.io> Date: Monday, June 8, 2020 at 10:59 AM To: "daos@daos.groups.io" <daos@daos.groups.io> Subject: [daos] global2local and local2global
Greetings,
DAOS supports the conversion of handles local2global and global2local. What are implications if any, if each process just perform local connect or open? Pool/Container/Objects.
From: <daos@daos.groups.io> on behalf of "Chaarawi, Mohamad" <mohamad.chaarawi@...> Reply-To: "daos@daos.groups.io" <daos@daos.groups.io> Date: Monday, June 8, 2020 at 12:25 PM To: "daos@daos.groups.io" <daos@daos.groups.io> Subject: Re: [daos] global2local and local2global
Hi Colin,
The major advantage of using the l2g, g2l is performance.
Doing a 1 per process call to connect / open is issuing an RPC to the server side, and pool / container operations are expensive.
Those functions are there to improve performance in cases where clients can communicate and share the handles vs all going to the server side. If clients can share those handles, we definitely encourage doing
that vs doing an independent pool connect or container open.
(note: similar functionality exists for dfs_mount)
Think of it as something like a file open. Middleware over parallel filesystems today try to improve performance of open by having 1 opener and sharing the open file handle to other peers (especially in an
MPI environment when you have a collective open, and that is if the PFS supports such a thing). PFS that do not have this feature often struggle performance wise in the open phase.
Thanks,
Mohamad
From: <daos@daos.groups.io> on behalf of Colin Ngam <colin.ngam@...> Reply-To: "daos@daos.groups.io" <daos@daos.groups.io> Date: Monday, June 8, 2020 at 10:59 AM To: "daos@daos.groups.io" <daos@daos.groups.io> Subject: [daos] global2local and local2global
Greetings,
DAOS supports the conversion of handles local2global and global2local. What are implications if any, if each process just perform local connect or open? Pool/Container/Objects.