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