Hey Julian,

> we talked about adding a request ID to the system interface. Therefore I think
> we discussed adding a new  parameter all system interface calls which can be
> set from MPI or the client core. I think when we extend the list of
> parameters then we could easily add another parameter as well, if needed.
> Thats why I bring it up in this email :)
>
> Background:
> Our working group in Heidelberg is interesting to give the client the ability
> to set the nodes on which the datafiles will be created instead of choosing
> them randomly, I think we had a patch somewhere, but I think it used another
> distribution and did never work clean so that you could integrate it easily.
> Instead of introducing another distribution I was thinking that this might be
> useful for all distibutions, so maybe a new parameter can be given to
> *sys_create which contains the names (!) of the servers on which the
> datafiles should be generated. Or maybe another flag struct could be used and
> can be extended for other use cases as well ?
> The client sm could use the server names during
> create_datafiles_setup_msgpair_array and set them according to the names
> instead of using PINT_cached_config_get_next_io to determine the datafile
> servers.
>

Aren't the two issues (adding a new parameter to the system interface and
the ability to create dfiles on specific nodes) sufficiently
orthogonal/different?
Can you tell us what exactly was the problem with the new distribution?
Adding server locations to sys_create() does not seem like a great way
forward.
Perhaps, we could use the extended attribute features on a directory
to indicate locations of servers for dfiles on a file create? Look at
this..
http://www.beowulf-underground.org/pipermail/pvfs2-developers/2006-June/002140.html
Thanks,
Murali
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers

Reply via email to