Right now, we are leaning towards changing trove, but a decision hasn't been made yet.
Thanks for your input! Becky -- Becky Ligon PVFS Developer Clemson University 864-650-4065 > I think either changing the key or adding separate pools per type would > work fine (and probably require a similar amount of work?). > > The former would mean modifying Trove. Trove does not currently expose > the functionality needed to skip to a subset of keys and remove one > (which would translate into a DB range query and delete). On the plus > side, if you did this then the job.c modifications would be relatively > minor, mainly just passing a little extra information around. > > The latter (adding more pools) would mean modifying the job.c precreate > functions a little more seriously to understand how to post operations > to different pools for different object types. But you wouldn't have to > mess with Trove if you go that route. > > I think either would perform fine, its more a question of whether the > job precreate functions or trove sounds less scary to hack on. > > I agree that you wouldn't want to have to iterate all the way through > the pool to find the right kind of handle. That would be bad news for > concurrent create operations. > > -Phil > > On 07/29/2010 10:53 AM, Rob Ross wrote: >> Maybe we should have one pool per type per server? -- Rob >> >> On Jul 29, 2010, at 9:48 AM, Walter Ligon wrote: >> >>> Hello everyone. We have a bit of a quandry ... we have found >>> ourselves wanting to use preallocated handles for more than just >>> datafiles. We decided we could populate the pools with handles of >>> various types, but now the interfaces seem to be presenting a problem. >>> >>> Our idea was to change the current record structure which (as I >>> understand it) is: >>> >>> key value >>> pool-handle:remote-handle <void> >>> >>> to: >>> >>> pool-handle:type:remote-handle <void> >>> >>> >>> which would figure would allow us to locate the handles of the right >>> type, and then grab one, but apparently the iterate-handles method >>> assumes you will search only for the pool-handle ... >>> >>> so we're contemplating changing that interface, but I am generall >>> loath to make such a change and would value whatever input you have. >>> >>> As an alternative we have thought about modifying the record to store: >>> >>> >>> pool-handle:remote-handle type >>> >>> and pass in a call back that tests the value for the desired info. >>> This also is an interface change, and worse, might have to skip over >>> hundreds of records to find a type it wants. >>> >>> Another idea was to have multiple pools per remote server, but this >>> would involve messing with a number of algorithms that pick between >>> servers (which seem to assume there is one pool per server). >>> >>> Any thoughts? >>> >>> Walt >>> _______________________________________________ >>> Pvfs2-developers mailing list >>> [email protected] >>> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers >> >> _______________________________________________ >> Pvfs2-developers mailing list >> [email protected] >> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers > > _______________________________________________ > Pvfs2-developers mailing list > [email protected] > http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers > _______________________________________________ Pvfs2-developers mailing list [email protected] http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
