significant performance / usability regression from fdatasync(2) change

[slingamn]

d442793 added an fdatasync(2) for each metadata update. Each such operation can be quite slow on HDDs (I'm measuring them at 15-30 milliseconds per operation with strace -T). With two such operations per active torrent, and 1000 active torrents, the main thread (including the UI and all upload and download activity) will freeze for approximately a minute during the periodic session_save operation:

rtorrent/src/main.cc

Line 358 in ee12073

"schedule2 = session_save,1200,1200,((session.save))\n"

resulting in only 95% availability for the client, since the operation is scheduled every 20 minutes.

I'm wondering if there could be a better way to handle this? Some possible ideas that come to mind:

1. Trigger sync(2) on a separate thread after all metadata updates are complete
2. fdatasync(2) on individual files, but on a separate thread via some kind of message passing
3. Make the file format more resilient to corruption (although that might not resolve all the concerns mentioned in jesec/rtorrent@f9a875b )

Thanks for your time.

[rakshasa]

The issue is that we need to wait for the files to be sync'ed before calling rename.

This makes it easy to fix the blocking issue as the rename can be done lazily in a separate thread.