> 	This has very little, if any, benefit, since once the data is
> written, it will be flushed to disk soon enough unless the machine
> crashes, and if the machine crashes, it could just as easily crash
> before the fsync().  And besides, it'll probably take more than five
> minutes to come back up, this making the replay cache irrelevant :-).

Unfortunately(?), some systems can come back up much quicker than that. 
But maybe we can figure out some way to deal...  Tom and I kicked around
a few ideas, but didn't get to anything beyond either doing the fsync,
skipping the replay cache altogether because the protocol makes it
unnecessary, or suffering with the replay vulnerability.

I did a little testing tonight, using a program that just adds to the
replay cache as quickly as it can for about five minutes, and when I
disabled the fsync call, the program ran faster by about a factor of
four, and it didn't keep the Linux kjournald process busy the whole
time.  But even with the fsync call, I was able to add around 1200
replay cache entries per second on average.  (Starting with an empty
cache, not running long enough to trigger an expunge, etc...not a
perfect test by any means.)