I updated from 13.1 to 13.2 (x64) and now I have constant hard drive flail. Constant. Tried searching on this - how can I diagnose?
Is there anything apparent running. ‘top’ might help identify
Which file systems are employed? Do you have btrfs by chance? Ignore this post if not. (Otherwise, perhaps it’s an issue with snapper configuration.)
A couple more possibilities:
- Is it swapping? If you have used all of your ram (and more) it might be. Of course, that would then raise the question of why you have used more ram than you once did, and there ‘top’ or ‘ksysguard’ might help.
- Possibly more likely is that you have one of the ‘file indexing’ apps running. If you are running kde, it rather easy to end up with ‘akonadi’ (or whatever it is called in the most current incarnation) running without intending to. There will be tutorials on how to turn this kind of stuff off, because sometimes it is another feature of kde that implies the use of akonadi and you have to turn that other feature off, too (all part of the ‘semantic desktop’, which will probably improve to the point of usability sometime - in the meantime, most people would prefer ‘off’, but kde don’t seem to see that as enough to make it an ‘off by default’ feature, or a ‘big warning if you switch it on’ one).
(Alternatively, if it is a file indexing application (should include ‘updatedb’, which runs find to do the back-end stuff, last time I looked and which is in turn needed by ‘locate’), you could just let it run to finality, and then it will be somewhat better behaved. However, the chances are it will start again at some other inconvenient time, and then you’ll get annoyed. For some reason, updatedb doesn’t seem to be as irritating as akonadi, perhaps because I can actually see the advantage of having locate working.)
If this is a box that is on continuously, maybe an alternative is to run these indexing things at a non-inconvenient time (eg, 3:00 in the morning). That can give you the best of all worlds - all the ‘locate’ or ‘semantic desktop’ stuff works, but it doesn’t interfere with normal use. But. for most people, an ‘always on’ box is not what they want.
Anyway, kdeguard (sometimes known as ‘system monitor’) can be very helpful in these cases. You can configure the ‘Process View’ tab to display ‘IO Read’ and ‘IO Write’. If one of those figures is high for some application, it should give you a big clue.
I have read in other threads elsewhere (awhile back since I last saw it mentioned, though) that the new indexer in 13.2 does some very major, heavy indexing after first install. See if it settles down in a day or so, or hunt for one of those threads and see how to change the settings to less aggressive.
BTW: I disabled the default indexers and instead use Recoll. Like it way better.
Hi Folks - thanks all for the replies. I tried a monitor (but not ‘top’) but they’re not very good at reporting disk transfer rates. It shouldn’t be swapping (16GB RAM with only 10% or less utilization) - gkrellm shows spikes in disk activity, not large constant activity. I get the “thrash” observation from the disk activity LED. I let it run for a half hour and it’s still going. It stalls app loading rates (e.g., Firefox), the KDE desktop, and sometimes even the mouse.
Is Recoll in the repos? What apps to disable default indexing? I tried killing krunner.
KDE?? If so. Configure Desktop - Desktop Search
top will show what programs are using CPU which may point to the culprit.
iotop does more or less the same for disk activity (you may have to install and it runs as root)
Yes.
What apps to disable default indexing? I tried killing krunner.
In 13.2, Baloo has replaced Nepomuk.
See this thread:
https://forums.opensuse.org/showthread.php/496936-How-long-before-Baloo-lets-me-have-my-CPU-back
I thought I replied to these suggestions, I guess not… anyway, in 13.2x64, I turned off desktop search (from Configure Desktop) and bam the disk stopped flailing (I actually jumped). It had been flailing for about 20 hours with no sign of slowdown. I was beginning to think I was being hacked. I have two 1TB HD’s - Ext4 and an eSATA BTRFS. I’m not sure now which one was flailing, it was the casefront LED which was flashing. But, as luck would have it, I needed to roll back to (i.e., reinstall) 13.1. 13.2 just can’t handle my two GPU cards, but 13.1 can (in 13.2, even the installer can’t handle them). Odd. I’m tempted, on a long weekend sometime, to do an online dup to 13.2 and see how that runs… 
Why not a zypper dup on 13.1? It is a different case compared to install a fresh 13.2 what I found out testing ;). But dont blame me later 
Why are you using btrfs on a esata (no critic, I may have missed some benefits there)?
regards
I have encountered a similar problem: constant disk activity right after installation of opensuse 13.2. I was able to find out that the desktop search was the culprit. With some difficulty, I disabled it. Also, had a bad filesystem failure with Btrfs, and have switched to ext4.
The twenty-hour-long disk activity tells me that possibly the program couldn’t handle links, or broken links, or wrong links properly. File handling utilities sometimes fail when they encounter logical errors in links.
No issues here with search ON
AFAIR the chatter only lasts a day or two, depending on the amount of initial indexing it must do. Once initial indexing is complete, I understand it settles down.
I am sitting at 13.1 for the time being until I get a block of time to start 13.2 installs on some of my machines, so I cannot really comment on Baloo, other than what I heard.
However, even in 13.1 I disabled Nepomuk and I am using Recoll from the repositories, instead. Much prefer it.