[Pvfs2-developers] crdirent

[Sam Lang]

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
> Pvfs2-developers at beowulf-underground.org
> http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
>