[PVFS2-developers] Multiple trove implementations
rross at mcs.anl.gov
Tue Oct 18 11:04:55 EDT 2005
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
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:
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...
More information about the PVFS2-developers