I'm running geany 1.32 on UbuntuMate64 18.04.1.
There is a 128GB EXT4 USB stick mounted. Its user directory contains a bash script and a subdirectory to hold backups.The script's action is to backup some of what's on my HD home directory into that subdirectory. The actual backups are done with a mixture of cp and rsync commands. The "from" specifications are mostly directory names that get processed recursively and contain up to 8GB of nested data and subdirs. Rsync calls may filter with --exclude.
When the freezes occur, I've begun editing something in the stick's user directory. Then I start running the script in mate-terminal. Next I go back to geany and try to save it with either ctl-s or the menu. Nothing happens for a substantial length of time - then eventually the operation completes.
I looked at the process table during one of these freezes. The geany process status was shown as noninterruptible. That accounts for the observed behaviour, but why should geany go noninterruptible?
Quick guess is Geany is waiting on IO which is being monopolised by the backup.
Don't see how. The destination directories are all below the the file I'm editing. The source directories are all on a different device.
If you are backing up to the stick so its writing bulk info to the stick and when editing on the stick so Geany is writing the file to the stick, so both are accessing the USB stick at the same time, and the interface to the stick is the bottleneck.
That makes sense, but I thought there'd be chunking of cp/rsync transfers so that more than 1 process would have access to the device. I expected there might be lockout at the direcory level - that's why the backups have their own directory below the files I'm writing. I'll look through the collection of rsync params to see if that can be specified. Thanks.
Probably the backup queues lots of IO requests that fill the queue, and Geany requests are therefore delayed by queue length between them.
And also IIUC flash memory can be slow if its doing erasures. Normally they are aggregated and done in periods of low activity, but with the backup running writing large amounts of data, they probably are forced to happen during the process, slowing everything down more.
Not much we can do, it's up to the OS to schedule I/O.
Closed #1982.
github-comments@lists.geany.org