[Pvfs2-developers] TroveMethod configuration parameter

[Sam Lang]

On Nov 28, 2006, at 12:34 PM, Phil Carns wrote:

>
>> The main issue here is that the trove initialize doesn't know  
>> which  method to use, so there needs to be a global default.   
>> Each  collection also gets its own method as you've noticed, so  
>> you can  specify that on a per collection basis.
>
> Ok- that makes sense.  Thanks for the confirmation.
>
>>> The pvfs2-genconfig utility places TroveMethod option in the   
>>> <Defaults> section.  Is this intentional?  For example, if  
>>> someone  edited a configuration file created by genconfig, they  
>>> might try to  change the value of TroveMethod from "dbpf" to "alt- 
>>> aio".  However,  it doesn't look like this would have any real  
>>> impact.  It would  change the parameter to trove's initialize()  
>>> function, but the  collection_lookup() would still default to the  
>>> dbpf method.
>> Hmm.. that's true.  The config format and the trove interfaces  
>> don't  match up real well.  Ideally, there wouldn't be a  
>> TroveMethod in the  <Defaults> section at all, and the trove  
>> initialize would work on a  per-collection basis, but right now we  
>> store collection info in both  the config file and inside the  
>> collections database.  To be able to  open and read from the  
>> collections database, we need a trove method.
>> Maybe it makes sense to use the default from the <Defaults>  
>> section  if one isn't specified for that collection?  I'm not  
>> crazy about this  solution but it seems like a reasonable  
>> alternative.
>
> That seems a little more intuitive.  Most people editing the config  
> file would probably expect behavior like that (not knowing what the  
> trove stack looks like).  Here are a couple of other ideas to throw  
> out there:
>
> B) split this into two keywords (hopefully with better names than  
> the examples below):
>
> - TroveCollectionMethod: valid _only_ in the StorageHints section
> - TroveStorageSpaceMethod: valid _only_ in the Defaults section
>
> C) keep the existing scheme, but just with two tweaks:
>
> - clarify the comments/documentation in server-config.c to indicate  
> that the parameter means something a little different depending on  
> where it is used
> - change pvfs2-genconfig to emit the "TroveMethod dbpf" line in the  
> StorageHints section rather than the Defaults section.  That way  
> someone  who comes along later and edits the file would tend to  
> change it in the place that has an impact on server performance.

Good call.  I went ahead and committed both of these changes.

FWIW, I'm not crazy about the redundancy that we have for filesystems  
in the fs.conf and the collections.db.  Would anyone else be in favor  
of getting rid of the collections.db altogether?  I looked at the  
code, and the only time we ever use that db is when we create or  
delete a collection, or to verify that an fsid is valid.  pvfs2- 
showcoll uses it to print all of the collections, but for all these  
cases we could just use the entries in the fs.conf, or look for  
actual directories in the storage space.  The advantage to removing  
the collections.db would be that trove_initialize wouldn't need a  
method for itself, independent of the individual collections.  Thoughts?

-sam

>
> For what its worth, I am going option C) here for the time being at  
> our site.
>
> -Phil
>