Bug 450696

Summary:	Copying large amount of files locks up KDE. cp / rsync no issue. So def Dolphin.
Product:	[Applications] dolphin	Reporter:	dft <dieseltrike>
Component:	general	Assignee:	Dolphin Bug Assignee <dolphin-bugs-null>
Status:	REPORTED ---
Severity:	normal	CC:	kai, kfm-devel, nate, postix
Priority:	NOR
Version First Reported In:	21.12.2
Target Milestone:	---
Platform:	Other
OS:	Linux
See Also:	https://bugs.kde.org/show_bug.cgi?id=423187
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Bug Depends on:
Bug Blocks:	504984

Description dft 2022-02-22 09:26:20 UTC

SUMMARY
If I copy large files say around 20G over lan / autofs / ssh etc KDE Plasma tends to lockup for minutes at a time. Over LOCAL mounts. 

If I do the exact same using konsole and cp / rsync. Plasma is responsive. Music will continue to play but the whole desktop will freeze up, shortcuts won't work, virtual desktops won't work. Screen repaints won't work.


STEPS TO REPRODUCE
1. Setup  a local mount of sshfs via autofs
2. Copy and paste a large folder say a tv series

OBSERVED RESULT
KDE Plasma hangs and ignores input. It does NOT crash.

EXPECTED RESULT
Dolphin's file copy operations should run in their own threads and not hang the DE.

SOFTWARE/OS VERSIONS
Operating System: ArcoLinux
KDE Plasma Version: 5.24.1
KDE Frameworks Version: 5.91.0
Qt Version: 5.15.2
Kernel Version: 5.16.10-arch1-1 (64-bit)
Graphics Platform: X11
Processors: 32 × AMD Ryzen 9 5950X 16-Core Processor
Memory: 31.3 GiB of RAM
Graphics Processor: AMD Radeon RX 5700 XT

Comment 1 Kai Krakow 2025-05-30 08:46:16 UTC

I can observe a similar behavior even with local file copies. It's less severe overall for me but my observations are the same: copying via cp or rsync usually works better and doesn't block GUI threads like plasmashell (partially or completely).

When using the GUI to copy files, one can observe extremely spiky throughput where e.g. network copies would sometimes spike to 200-300 MB/s (way above my 1 GBit/s link), then freeze the GUI for multiple minutes while the shown throughput goes down to 2-3 MB/s ("freeze" means it's not accepting input but usually still updates most of the widgets).

This looks like the GUI is saturating the writeback cache, and it should not do that: Once the GUI starts to dominate the page cache due to this behavior, almost any other file operation in the GUI will become a blocking operation.