https://bugs.kde.org/show_bug.cgi?id=401088
--- Comment #48 from SoftExpert <softexp...@gmail.com> --- (In reply to Steve Vialle from comment #47) > (In reply to SoftExpert from comment #46) > > My 2 cents here: I believe the issue is outside Plasma entirely and purely > > systemd related (more precisely systemd-fstab-generator related) > > Same problems occur with openrc, so I really don't see how it has anything > to do with systemd. > > I see your 2c, and raise you my own: > All of this has the same common cause, namely that Plasma can't handle slow > system mounts (i.e. not KIO VFS) of any kind gracefully, because the UI > thread blocks on some filesystem call (likely a stat and/or something in > solid collecting file metadata). > This leads to "filesystem not responding" [s]messages[/s] band-aids > appearing well after they are useful, dolphin freezing if a system mount > (e.g. NFS or a busy mechanical disk) is slow to respond or inaccessible, and > all the other bug reports regarding poor performance and responsiveness > problems with remote (i.e. high latency) filesystems. > > The solution is quite obvious (though the implementation is probably not > straightforward): Do not block the UI thread on filesystem operations, and > provide some feedback as to why directory contents are slow to update > (ideally with a timeout or manual way to cancel loading), again in a > non-blocking manner so this information shows up when it's actually useful. > > Windows 95 had far, far better handling of slow filesystems (remember that > flashlight animation?), why we're still trying to come up with excuses and > shove this fundamental design problem under the rug in 2024 I have no idea. I understand and share your frustration. I guess there are, indeed, 2 distinct problems combined and highlighted by this bug : 1. the need for a better design of the KIO - UI interaction, making it truly asynchronous 2. potentially, NFS could be made to behave - by carefully selecting more effective parameters. When NFS is better configured, since it can approach in a different way the connection to network resources that are not yet available, KIO will have to wait very little time, so it appears in the UI like a fast operation; when NFS is badly configured or encounters a problem and, stubbornly, tries to handle the issue in synchronous mode, KIO will wait for the result to become available and will block the UI thread - and this is the part that can an should be addressed by this bug. Did I resume it correctly ? -- You are receiving this mail because: You are watching all bug changes.
