slang at mcs.anl.gov
Tue Jun 13 11:43:20 EDT 2006
On Jun 13, 2006, at 9:14 AM, Rob Ross wrote:
> Sam Lang wrote:
>> On Jun 12, 2006, at 10:07 PM, Rob Ross wrote:
>>> i know we're trying to keep the # of DBs down, but would it
>>> really hurt that much to just use a separate DB for this data
>>> rather than having to play funny games with the key strings?
>> I don't have much preference either way. I don't find the null
>> string to be that much of a hack, but I can see the advantages of
>> having a separate db for stuff like this. One disadvantage of
>> separate dbs is that we can't just do one sync at the end of a
>> crdirent or rmdirent.
> that's a very good point.
>>> also, it seems a little wacky that we have to pass a flag to tell
>>> trove when to count and when not to count. is there a clean way
>>> to avoid that?
>> This is the problem that dbpf doesn't know anything about the
>> common keys. We could copy the common keys in the dbpf layer,
>> kind of an ugly hack though. Also, the crdirent and rmdirent
>> calls just give a handle and the component name, so we really can
>> only tell the difference between common keys and everything else (!
>> is_this_a_common_key(key)). In this case that will either be a
>> component name or an xattr. So we'd only be able to do as good as
>> counting both xattrs and directory entries.
> so maybe xattrs belong in a separate DB? i dunno. i don't really
> mean to open up the DB organization discussion again, but it seems
> like we're just a little off...comments?
Hmm..that would make the xattr code a bit tricky I think, since right
now the common keys are considered xattrs in some cases (viewdist for
example). It might be possible to add checks to the code and branch
to different dbs, but I kind of like the idea of common keys (and
even components if you have the dirent handle) just being xattrs from
the client's perspective.
It seems like we're looking for a clean way of identifying the handle
from within the dbpf layer, and storing metadata (metadata on the
metadata ;-)) on that handle (independent of the other keyvals on the
handle). The only ways I can think of doing that is by either
changing the trove api or passing in a flag that specifies the type
of handle being operated on. The TROVE_KEYVAL_HANDLE_COUNT does that
to some degree, although perhaps just specifying the type of handle
as a flag for each of the trove_keyval calls we make instead of
passing in a flag that specifies the count to be modified makes more
sense? That would let the dbpf layer figure out what it should do
(increment count, etc.) based on the handle type.
>> We talked about just adding the count to every handle in the
>> keyval db. That adds a bunch of unecessary keyval entries (for
>> each file and directory). I was trying to avoid that, but maybe
>> the cost isn't worth the hastle.
> that makes good sense and helps motivate the use of those special
>>> how do you read the count?
>> There's an additional trove_keyval_get_handle_info function.
> ok. seems like we're really close here. i'm ok with the solution
> you proposed, but if there is some slight tweak to the storage
> organization that helps make things a little cleaner...
More information about the Pvfs2-developers