Need More Info from DUNS Attribute
|
Zhang, Jiafu
Hi Pittman,
Thanks for the info. Please let me know when your ticket is done. I’ll move the attributes from UNS path to container.
Thanks.
From: daos@daos.groups.io <daos@daos.groups.io> On Behalf Of
Pittman, Ashley M
Sent: Friday, May 15, 2020 6:32 PM To: daos@daos.groups.io Cc: Wang, Carson <carson.wang@...>; Zhu, Minming <minming.zhu@...>; Guo, Chenzhao <chenzhao.guo@...> Subject: Re: [daos] Need More Info from DUNS Attribute
Hi,
Server_group certainly seems a useful thing to add, service ranks I thought was scheduled for removal but would also make sense if it’s still in use. I can file a ticket and work on this as part of the current dfuse work I’m doing. You might be interested in https://github.com/daos-stack/daos/pull/2557 which allows you to run “daos container create –path <path> and then “dfuse –mountpoint <path>” and have dfuse load the pool/container from the xattr.
Things like application info should be in container attributes I suspect, and chunk/cell size should ideally be in the array objects themselves. This is something that’s currently hard-coded in both dfs and the interception library so we need a mechanism to communicate those values at run-time but it would be on a per object basis.
Ashley,
From:
<daos@daos.groups.io> on behalf of "Zhang, Jiafu" <jiafu.zhang@...>
Hi Guys,
Currently, there are only three info set to duns attribute of UNS path. They are FS type, pool UUID and container UUID. It’s enough for dfuse since dfuse’s server group and service ranks are used to connect to the pool. Do you know if Lustre will use the same way to connect to pool ?
For Hadoop DAOS, customer seems not want to keep additional info outside of UNS path. Can we expand the duns attribute ("user.daos") to hold more info, like server group and pool service ranks? Or we can use another attribute name, for example, “user.daos.hadoop”, to hold even more application info, like read and write buffer size?
Thanks. --------------------------------------------------------------------- This e-mail and any attachments may contain confidential material for |
|
|
|
Pittman, Ashley M
Hi,
Server_group certainly seems a useful thing to add, service ranks I thought was scheduled for removal but would also make sense if it’s still in use. I can file a ticket and work on this as part of the current dfuse work I’m doing. You might be interested in https://github.com/daos-stack/daos/pull/2557 which allows you to run “daos container create –path <path> and then “dfuse –mountpoint <path>” and have dfuse load the pool/container from the xattr.
Things like application info should be in container attributes I suspect, and chunk/cell size should ideally be in the array objects themselves. This is something that’s currently hard-coded in both dfs and the interception library so we need a mechanism to communicate those values at run-time but it would be on a per object basis.
Ashley,
From:
<daos@daos.groups.io> on behalf of "Zhang, Jiafu" <jiafu.zhang@...>
Hi Guys,
Currently, there are only three info set to duns attribute of UNS path. They are FS type, pool UUID and container UUID. It’s enough for dfuse since dfuse’s server group and service ranks are used to connect to the pool. Do you know if Lustre will use the same way to connect to pool ?
For Hadoop DAOS, customer seems not want to keep additional info outside of UNS path. Can we expand the duns attribute ("user.daos") to hold more info, like server group and pool service ranks? Or we can use another attribute name, for example, “user.daos.hadoop”, to hold even more application info, like read and write buffer size?
Thanks. --------------------------------------------------------------------- This e-mail and any attachments may contain confidential material for |
|
|
|
Zhang, Jiafu
Hi Guys,
Currently, there are only three info set to duns attribute of UNS path. They are FS type, pool UUID and container UUID. It’s enough for dfuse since dfuse’s server group and service ranks are used to connect to the pool. Do you know if Lustre will use the same way to connect to pool ?
For Hadoop DAOS, customer seems not want to keep additional info outside of UNS path. Can we expand the duns attribute ("user.daos") to hold more info, like server group and pool service ranks? Or we can use another attribute name, for example, “user.daos.hadoop”, to hold even more application info, like read and write buffer size?
Thanks. |
|
|