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
