AFAIK there are two possible reasons for this behaviour: 1) In Preferences->Download the option 'Pre-allocate disk space for all files' is checked (but that's not the default). 2) The option above is not checked but the download folder is within a filesystem that doesn't support sparse files (at least on Linux) like FAT32 and exFAT. Assuming that sequential download is not checked, when a torrent piece located GB away from the file beginning is received, the file has to be extended by physically writing zeros to seek to that position and write the piece.
When downloading to filesystems with sparse file support (like ext4 for example) I could not observe such I/O overload, even with file preallocation (at least with recent versions of libtorrent-rasterbar). OTOH the issue is still present for downloads to certain filesystems (i.e. FAT32, etc) and can cause severe performance issues especially with slow storage. Regards BZ
