Hi,

I'm experiencing a strange issue. First of all, this isn't a common situation and most likely no one ever had or would come across this situation. But to me it happened and the consequences are staggering.

Secondly, I'm not exactly sure it is KDE related, but after some investigation that's my best bet.

OK, here's what happened: I've been the victim of a stupid 'joke' by the system administrator at my work. He's a nice guy, we like to trick each other, so one day when he found out that there's an open samba share residing on the root partition on my box, he did the following:
With a tiny shell script, he wrote a number of millions of EMPTY zero byte files to that share. This was intended to show how a Linux system is collapsing with loads of free disk space on the root device if it runs out of inodes.

Anyway, lesson learned, share closed, files removed with a reverse version of the script.

BUT... ever since then, when I open Dolphin (by default at my home directory which contains the affected shared directory), it hangs for 6-8 minutes. (This is a quad core Dell Studio box.) Dolphin application window is unresponsive and there's extremely heavy disk usage and high load during this time.

When I open a shell in a terminal and list the directory contents of my home or the affected directory (before, after or during dolphin's hanging), it all goes fine. No delay or screwing hard drive at all.

I'm not sure if it's related to Dolphin, KDE or something else. I'm hoping for a simply solution like removing some internal caches of Dolphin or similar.

Any ideas, please share.



Best Regards,
Marcel

Moved to Other KDE Software.

That's a pretty interesting problem. Can you please check if
1. you can reproduce in other file managers (Konqueror? Non-KDE file managers?)
2. you can reproduce it with another (new) user.

Hi Hans,

Thanks for your reply.

Some more findings: apparently this issues doesn't depend on KDE session. Meaning that when I start up the system it will happen for sure, but then within the same KDE session it WILL reoccur after a while. Also, it will not reoccur even if Dolphin is closed and reopened if it happened recently. I don't know what it depends on but Dolphin can be closed and reopened and it wont happen again for a while and will after a while.

Apparently the scope is more global than Dolphin's. I just tried with Konqueror file manager mode in a KDE session where I had it happening with Dolphin not long ago and it didn't happen for Konq. but I have the feeling that if Konqueror is the first to scan my home folder, it would happen too. Will confirm this later.

I'll do some more tests with new user, see if I find some correlation between KDE session state and the issue, etc. But obviously, the last thing I want is to 'reproduce' the problem in its entirety, that is, to fill my root partition with inodes and then remove them.

Regards,
Marcel

I can confirm now that ending KDE session (even X is restarted) does not cause the issue to reoccur. However, if I leave the active KDE session, almost sure it will happen again next day.

I found that it depends on the system user. Here is what I did to confirm this:
- create new user
- restart system
- login with new user
- start konqueror, dolphin - all fine
- logout, login to old user
- start dolphin - problem occurs

Is strigi indexing enabled? Was the share indexed?

Have you tried cleaning out your temp, cache, and thumbnails directories?

TheBlackCat wrote:Is strigi indexing enabled? Was the share indexed?

Have you tried cleaning out your temp, cache, and thumbnails directories?

Hi,

KDE settings such as strigi are mainly default on this work machine. Nepomuk is enabled Strigi is not. I haven't touched these settings.

The issue happened over 2 month ago. I left it some time to 'clear up' but it didn't.

System /tmp was emptied many times since then (system restart). I just emptied the .thumbnails and .cache in my home. Neither appeared to suspiciously big in size though. Will restart now to see if helped.

Any other ideas?

Thanks,
Marcel

No luck, it is happening now just after restart. This time there's a little difference. I don't think it's related to the changes but maybe: so far what always happened is that Dolphin window became unresponsive before showing any content. Now, it showed the file listing of my home dir and I could even scroll down but then it started, window froze and it took 8 minutes again.

Try booting from a Live CD and running a force fsck on your root file system. Do you use a seperate file system for /home?

bcooksley wrote:Try booting from a Live CD and running a force fsck on your root file system. Do you use a seperate file system for /home?

Hi,

I've already done force fsck on the affected partition. Home and root are the same block device.

Since the base system doesn't show sings of misbehaviour, I suspect the problem's root should be in KDE's scope.

Try deleting /var/tmp/kdecache-$USER/ outside KDE.

I cleared up a similar sounding problem by deleting ~/.kde/cache-$HOSTNAME

Thanks for the input Everyone,

After the weekend during which the machine was turned on, I found the following. Dolphin didn't produce the issue when I opened but a few minutes later when I clicked the save button in Kate AND then navigated from the default ~/Documents to ~ then it started again. (The affected directory was ~/temp) It is strange, because Dolphin opened at ~ as well.

Even though I'm a developer and an advanced Linux user, I know little about KDE so I don't want to draw conclusions, but this suggests the fault may be on application level.

Now I will try the suggestions from the last 2 replies.

The above seems to be unrelated.

I stopped KDE session, logged in as root on a tty, killed kdm, then removed /var/tmp/kdecache-$USER. Rebooted the system, logged on to KDE, opened Dolhin and here we go again.

Annoying. It's not that I can't live with it, as said, it's a work machine. I could start using another user or even get the system re-installed but I just want to know what's causing this...

Sorry, I gave misleading information in the beginning saying that the base system is not affected. When I tested that, I listed my home on a tty but not the ~/temp (stupid me). Obviously, Dolphin pre-fetches the direct subfolders of the opened location.

After a restart, I just cd-d int ~/temp and did an ls and it started.

Further, when I killed /sbin/login of the user on that tty (kill -9) it did not stop the ls command. When I tried explicitly killing the ls command, nothing happened as well.