Bug 336251 - On startup, KDE scans $HOME directories extensively: Huge delay
Summary: On startup, KDE scans $HOME directories extensively: Huge delay
Status: RESOLVED WORKSFORME
Alias: None
Product: kde
Classification: I don't know
Component: general (show other bugs)
Version: 4.11.5
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-15 03:22 UTC by yanestra
Modified: 2014-06-30 23:41 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
iotop -ob during kde startup (62.17 KB, text/plain)
2014-06-24 15:17 UTC, yanestra
Details

Note You need to log in before you can comment on or make changes to this bug.
Description yanestra 2014-06-15 03:22:36 UTC
I have discovered, that KDE under OpenSUSE 13.1 scans $HOME directories extensively.

According to atime (after having mounted /home with strictatime), 3479 files of 2045892 are not only being scanned, but also opened. Apparently without reason.

The result is a big delay on startup.

Reproducible: Always
Comment 1 yanestra 2014-06-15 04:04:02 UTC
Also reported as 882756 with OpenSUSE bugtracking system.
Comment 2 Christoph Feck 2014-06-15 07:43:06 UTC
Does disabling Desktop Search (Nepomuk) services solve the issue? Please ask in a help forum how to disable it.
Comment 3 yanestra 2014-06-16 07:41:43 UTC
Nepomuk (Desktop Search) has been disabled prior to my observations.
Comment 4 Christoph Feck 2014-06-16 12:01:16 UTC
Could you please check which process is scanning the disk? You can either try the system monitor (Ctrl+Esc), "top" command in Konsole, or other monitors, such as iotop.
Comment 5 yanestra 2014-06-24 15:15:44 UTC
I have executed iotop -ob for the time of the KDE startup process (now quite lengthy) and I get mainly

kdeinit4: kded4 [kdeinit]

as the main I/O process occupying I/O bandwidth.
Comment 6 yanestra 2014-06-24 15:17:43 UTC
Created attachment 87378 [details]
iotop -ob during kde startup
Comment 7 Christoph Feck 2014-06-24 16:30:20 UTC
Okey, that's the worst case. To investigate further, please try to find the kded module which is responsible. For more information, see http://kdepepo.wordpress.com/2011/05/11/troubleshooting-kded4-bugs/
Comment 8 yanestra 2014-06-25 04:17:41 UTC
Sigh. Startup time is now up to 4 minutes. I guess, after all, there isn't much choice but testing each and every kded module for being the reason for this, but isn't there any hint about a possible reason?
Comment 9 yanestra 2014-06-30 12:46:40 UTC
I have done many tests, and it appears, while the reason of the scanning itself is still unkown, the huge delay results from the initial file system latency with that large hard disks.

Or so to say, environments which do not scan the file system at all are fast, while those which scan even if just a little bit can get extremely slow, up to 4 minutes and more per logon.

Moreover, KDE SC has been cleared of the suspicion of spying. I set this bug to FIXED, while it isn't fixed, but appears to be a mere systematic problem.
Comment 10 Christoph Feck 2014-06-30 20:59:40 UTC
In other words, you gave up on finding which kded module was reponsible?
Comment 11 yanestra 2014-06-30 23:41:38 UTC
Yes, I gave up. While working on this, I asked myself why several directories were NOT scanned with which I would associate a meaningful relationship to certain daemon processes. Kind of creepy.