Are you sure it happened with the last update? You can change "Peer read caching" in Settings - Transfers category - Files. This is essentially read amplification to reduce the amount of random reads.
If Tixati tried to only read what it uploads, you would end up with almost 100% random disk IO and bad performance. Tixati tries to read ahead in anticipation what will be requested next. I suggest 2MB blocks for most upload speeds on an HDD. 4MB blocks for >100 MBit/s upload.
Another source of I/O is the endless rewrites of the config. Tixati does this in a crash-resistant way and iirc overwrites the files fully. This is not optimal and something like SQLite would be better fit for the job. Another idea is to have padded chunked saves where the most frequently updated data can be updated in-place like channel/torrent stats etc. while still keeping A/B dual configs for crash resilience. Now that I typed it out I think really the majority of config IO comes from the intent to have crash resilience and frequent saves of current data.
