[PVFS2-developers] metadata record pre-allocation

[Phil Carns]

> Yes, that appears to be the problem.  The internal db sync appears to
> sync a lot more than the metadata created -- and it's (partially) out
> of our control.  Phil ran a test a while back that overloaded the
> fsync calls (with an empty function) inside of the DB code and sure
> enough the performance is heavily improved ... but the data in the
> system was totally unsafe all across the board.  We talked for a
> minute about keeping it that way and doing our own syncs, but I think
> if we're going to go through the trouble (while complaining and
> 'fixing' the DB as it gets corrupt at weird times), we've so far
> worked around DB that it might be better to not use it all.  Which

As a side note somewhat orthogonal to this conversation, I never did figure 
out why calling fsync on a tiny db file clogged the whole server.  I would 
assume this is dependent on the kernel and underlying fs.  It appeared that 
an fsync call on any file, no matter how small, resulted in a full sync of 
the file system.  So for example, if you had just written 100 MB out to disk 
but hadn't synced, then the next fsync on a completely unrelated db file 
would suddenly pay the cost of hitting disk for 100 MB.  It was pretty easy 
to see this in action when importing large files.

If the fsyncs truly really worked as advertised and only caused the 4K 
database file to be synced, it doesn't seem like these sync stalls would be 
as painful.  If anyone has any insight into that issue (Is this known linux 
behavior?  I am off base in expecting otherwise?) I would be curious to hear.

-Phil