[PVFS2-developers] latest mpi-io-test numbers on jazz
robl at mcs.anl.gov
Thu Mar 31 15:57:41 EST 2005
On Thu, Mar 31, 2005 at 07:45:40PM +0200, Phil Carns wrote:
> There definitely needs to be some improvement here. I think the most
> important write graph is the "nosync" version, though. According to the
> rough calculations in the earlier email, that graph shows us getting 23
> MB/s per server, which is close to 75% of peak. Still not as good as we
> could be, though.
How smart is the request scheduler these days?
> I don't think that the runs with TroveSync set to yes really tell us
> that much. Those are forcing trove to sync after every individual
> underlying operation (which can be no larger than 256K each by default)
> whether the application wants it to or not. That's adding a good bit of
> superfluous work to a benchmark that is already syncing the traditional
> way by just calling a sync() function once at the end of a write. It is
> also probably causing blocks to flush to disk in an unusual order given
> the interleaving of data from many clients, therefore causing extra disk
Wow, I didn't realize we were syncing after every 256K bytes!
> PVFS2 ships with the default configuration files setting TroveSync to
> yes, though, so I guess that's really showing PVFS2's normal mode of
> operation. IMHO, I tend to think that turning TroveSync off is a better
> default choice. Maybe at least until we have a server controlled cache
> that prevents us from hitting trove unless we really want to hit
> physical disk. Applications still have the choice of deciding when/if
> to explicitly sync regardless of the TroveSync option.
I'm trying to learn how frequently berkely db will flush data if
clients never call db->sync. Even though we've worked out a lot of
sofware reasons for server crashes, we still see hardware blowups.
Just curious how exposed people are to data loss if sync is off.
Mathematics and Computer Science Division A215 0178 EA2D B059 8CDF
Argonne National Labs, IL USA B29D F333 664A 4280 315B
More information about the PVFS2-developers