I went ahead and committed the changes I made (with the HANDLE_COUNT
flag).
-sam
On Jun 13, 2006, at 10:43 AM, Sam Lang wrote:
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.
-sam
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
flags.
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...
rob
_______________________________________________
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
