Merging a branch using github desktop (at least 200 commits) will have the system freeze for at least an hour. Even the clock will not update during that time or will the system respond to any mouse movements, even trying to enter tty is a fruitless exercise until it’s done writing to disk. The disk indicator will flash throughout this time to show disk usage. I have 32 gb of ram, and 8 cores and an nvme ssd for storage, imagine how productive waiting for at least an hour is, for the system to respond to just a git merge.
Right now i am not able to check the smart status because it’s currently frozen. The disk is relatively new, less than 5 months old, came with the laptop. This usually happens if there is high disk writing. If i move the mouse it will respond after a long time, just a jump to a new position, in this time the fans would be frantically spinning. No way to recover the session besides a hard shutdown, which i am afraid will result in a loss of files.
I still have around 20gb on the btrfs, could the disk filling up be the issue?
Correct. under 5% free space is bad for btrfs. It should have at least 10-15% to breath. Using compression (zstd:9) would be also not a bad idea, when you use a lot small textfiles which is common on git repos; it would improve I/O a lot.
To add here: a large merge needs a lot of I/O of small files. When you are going to do a large merge, it would be better to do it in a tmpfs, so in the RAM, which speeds it up.
Thank you, is there a way to not have one app freeze the whole system. I have noticed also copying files using dolphin will have the system somewhat less responsive. How do i go about ensuring this doesn’t happen again?
Had to do a hard shutdown as i realised my day was going to be wasted waiting for the system to respond. Cleared a bit more memory to make about 32 gb of free space. The merge reports being completed an hour ago though the disk usage indicator was still flashing. Also SMART does not report any issues with the drive.
Commonly that shouldn’t happen, but in your use case it would be a better approach to do intensive I/O not on the same drive ( nvme0) as your root directory (so another drive or a RAM disk (tmpfs)), or you can use ionice to lower the I/O priority of specific apps, so that you DE has higher priority. I guess git and also github desktop has the same priority (20) as your desktop and therefore prioritize it equally what let it freeze.
It is totally normal to have none scheduler on nvmes, since it throttles I/O, while on other drives MMC/HDD/SSD that could be an speed improvement.
yeah i did not look up the specific nvme, but after looking it should be perfectly modern enough to not need help. Unless there is some firmware bug that is being triggered.
Then an additional issue for locking up is cpu scheduling, if some program is really thrashing the cpu stealing all time. The only fix for this was previously bfs/muqss but both of them are unmaintained so i have no idea what to do there. Maybe just increase nice value for the git process?
95.2%
