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
