[PVFS2-developers] Multiple trove implementations

[Rob Ross]

Hi Julian,

Sorry for the delay in response.

We've talked about just this sort of thing before, and Phil had 
implemented a different variation.  I think it's a good idea.

I agree that were we to have more than one trove implementation actually 
being used by people, that we would want something like what you 
describe in the config file.  It wouldn't hurt to go ahead and implement 
such a keyword.  TroveModule seems like a good name for it.  It would 
set a value in the filesystem_configuration structure that could be 
passed to map_coll_id_to_method() (which should really be 
trove_map_method() or something with a trove prefix, but whatever).  For 
the moment though, I think we would just ignore the keyword in the CVS 
version (since there's only one Trove implementation at this time).

Out of curiosity, what file system are you using for the DBPF and 
DBPF-nosync cases?

Looking at Meta-create-1Meta-5Data-1Clients-all.pdf, I see what you're 
saying about the metadata dropoff.  My guess would be that this is a 
Berkeley DB issue?  One thing that we haven't yet pursued is tuning 
Berkeley DB.  We've found some notes on this:
   http://pybsddb.sourceforge.net/ref/mp/config.html

On the read/write side of things, it might be more useful to look at the 
time rather than the bandwidth.  This will more obviously show how much 
time is lost in reading from/writing to the disk.

The IO-smallblock-10MB-1Meta-5Data-5Clients-all-Read+Write.pdf results 
are confusing, in particular the read performance.  Any ideas on why 
performance drops as it does?

If you can replicate the situation where PVFS2 is crashing, we would of 
course want to fix that!  We don't see that sort of thing here...

Thanks!

Rob