In the case of async fsync, currently we end up fsync-ing every timer period, even if nothing happened since the last time (so if you run fs_usage, you see a constant stream of fsync's even on an idle server, and for short syncJournal settings it's a lot of extra system calls, even though it's not actually hitting the disk). So this adds a check to fix that.
There's also a small re-ordering of the exception handling, so that if an IOException happens as part of fulfilling a Future, we don't mistake that for an exception during writer.force(), and set it on the other Futures.
robey
commented
13 years ago
In the case of async fsync, currently we end up fsync-ing every timer period, even if nothing happened since the last time (so if you run fs_usage, you see a constant stream of fsync's even on an idle server, and for short syncJournal settings it's a lot of extra system calls, even though it's not actually hitting the disk). So this adds a check to fix that.
There's also a small re-ordering of the exception handling, so that if an IOException happens as part of fulfilling a Future, we don't mistake that for an exception during writer.force(), and set it on the other Futures.