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?
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
