Booting my openSUSE sounds quite unusal to me;
abt. several dozens very quick head positionings in an interval of abt. 6s of 26s.
The interval in question is from 13s to 19s:
This kind of HDD access I only know from heavy fragmentation.
BUT
the system is installed on a SSD (btrfs); at HDD (ext4) there is only /home.
Moreover it’s only a few weeks since I did the installation;
and /home only consists of a few dozen files.
var/log/messages (as a newby I can’t assess if there is something conspicious):
As I’m still at the dual-boot Win-Linux hopping phase
(which will endure for some months I guess) I would prefer to prevent it.
It won’t be healthy for the HDD, and probably is unnecessary.
Grub just makes BIOS calls to access the disk. I would not expect this to be very efficient. It has to determine the file systems that are present, so it can read the boot menu.
Once your system has booted, the kernel should be using more efficient ways of managing the disk.
But the interval of massive HDD head positioning is abt. 13s (!) after the start of the boot process. System should be consilidated concerning disk access at this point, doesn’t it?
Addendum to var/log/messages:
It contains updating some packets.
Repeating the boot (with packets installed) the effect is the same.
So the updating is not the culprit…
A quick look at your logs reveals that about “13 seconds” your desktop is being initialized for the logged in user:
2024-09-29T21:47:52.847836+02:00 MarvinVI dbus-daemon[2194]: [session uid=1000 pid=2194] Successfully activated service 'org.kde.KScreen'
and about “19 seconds” you are welcomed in and soon thereafter PackageKit begins searching for software updates:
2024-09-29T21:48:02.218927+02:00 MarvinVI systemd[2001]: app-org.opensuse.opensuse_welcome@autostart.service: Consumed 2.140s CPU time.
In between the system is loading a bunch of small files from your /home folder to restore your preferences etc. Whether or not those files are contiguous depends on many factors, but I bet they are not, hence the HDD head moves to find and load them.
Unless it repeatedly bumps on the head rest / limit switch I see it as normal and expected for a /home on an HDD.
Thank you!
So, despite the (so far) very fresh system there will be “a bunch of small files for preferences” at /home…
Maybe KDE, KDevelop, and the pre-installed applications…
But in all my (Win) experience I never had such “drum roll” of head hop.
If you say “not contiguous” you won’t mean fragmented (FS scattering strategy will prevent that), but… well… files scattered all over the HDD (due to that very strategy), right?
And as my config (system-SSD, /home-HDD) will probably be quite typical,
I shouldn’t be the only one with that… (?).
Is there anything I could reasonable do to prevent that?
Quick hint … within your user’s home sub-directory (/home/userX), there is a hidden sub-dir named “.config”. This contains the various configuration files used by the DE and applications you use.
There is another hidden sub-dir that is named “.cache” … yes, that is basically a cache of the “.config”. That’s where the system goes first to avoid disk thrashing.
This is why, sometimes when you perform an update (as in “zypper up”) and you have issues with a browser, folks will suggest you delete the .cache entries. Deleting .cache has no detrimental affect - the system and apps will recreate their cache the next time they are run.
“not contiguous” means file fragmentation (fragmented). With a fairly new installation, I’d be hesitant to suggest fragmentation.
Personally, in this situation, we’d run a disk-drive monitor, and maybe a process monitor.
Not so long ago, we had constant disk write / read thrashing when we used TW (on all our machines). (we’ve since switched to Leap). It turned out to be the Baloo indexer (for KDE), which was well-reported as an issue. It was very obvious when running a process monitor) Don’t believe it, just do a search
We’ve disabled Baloo on all our systems - for us, not required.
I’ve the suspicion that it might be KDevelop’s handling of it’s preferences.
It could well be the effect arose after installing it.
Will try an uninstall.
If no change will say goodbye to Baloo (poor Baloo).
I will report…
Using a drive monitor and process monitor is done quite easily and will show results immediately, saving a lot of hunting around to figure out the culprit.
I’m not suggesting your issue is Baloo, I just used that as an example when we used the process monitor… within seconds, you could see Baloo at about 99%+ CPU usage.
First, I would recommend taking a step back and learning a little more about your system before changing the configuration. Yeah I know, you hear clicks and you don’t want to hear them. We can accomplish that without messing with baloo.
Regarding
is your Windows install on the rotational disk? Or if Windows is on the SSD, have you moved the Windows user folder and perhaps the ProgramData folder to the rotational disk? I ask because that would be the rough equivalent to your Linux installation. (Moving ProgramData is either not possible or strongly not advised.)
That configuration is unusual; if you want silence, you would put everything on one or more SSDs and use rotational disks for backups, NAS duty, or as an extra data disk. Your user directory is not just a place where you can, for example, store digital mementos, it is also the home to all of your user specific system configuration and many of the files that get generated along the way to provide a pleasant experience.
Using a Linux desktop system without accessing /home/your_username regularly is not possible. (Well it is, of course, possible but then the data has to live somewhere else, and it has to be accessed for the computer to be useful.)
Not in my words. My understanding is that a “fragmented file” is a single file with several chunks that are not contiguous. But here (from 13s to 19s of the boot sequence) we are dealing with multiple files.
In the system I’m writing from ~/.cache alone comprises 109 folders totaling 923 items: how do you expect those files being all in the same cylinder (= read head not moving) when every app you run possibly updates its share asynchronously?
I’m not saying that there is no problem on the system in question, but only that I’m not surprised to hear a read head moving during those 6 seconds of a boot sequence where the desktop is being initialized.
Yes, you can use any number of the variations of “top”. And yes, fatrace is a pretty good tool - we’ve used it with positive results.
If you’re using KDE, there is an “all in one” tool that shows disk accessing and processes. On the KDE system menu, select System → System Monitor. It can also be executed from the System → Info Center, then tap on System Monitor.
System Monitoring Center is a great tool.
Hey, wait a minute !! (doing a forum search) … you already have a lengthy thread discussing all this. Why have you posted this “duplicate” thread???
A typical moving of the read head wouldn’t surprise me of course.
But as I already stated it’s actually a 6s permanent “drum roll”
(That’s why I attached the audio file for illustration),
kind of I only encountered in massive different file accesses so far.
Never regulary at boot processes.
Once again I wonder why no one has confirmed the effect at his system…
If this is normal, it should be at about every system.
“Something is rotten in the state of Denmark”…
I disagree that it’s not a dup … the same subject matter, just worded differently.
It appears that you didn’t use the recommendations about monitoring CPU and disk (in the other post), so you could provide further (concrete) information about what is consuming CPU / disk usage in this post.
Folks in here are not watching over your shoulder and seeing results - it’s all speculation.
Although my system is quite “fresh” with only few applications installed
/home/.config has 166 files in 94 sub-folders and
/home/.cache has 4000 files in 418 sub-folders.
Uninstall KDevelop: no change in effect.
Disabled Baloo/ “file search” (deleted index file 52kB), then boot: no change in effect.
To my (not too short) experience with PCs, I suspect that this kind of massive
“drum roll” head positioning for 6s at every start points to something not alright.
For me it’s hard to believe this should be normal.
Sadly no one confirms/ regrets about that effect on his system (despite I made
and enclosed my sound example for that).
Being still a newbie, at this point I don’t know which monitor to use (and how)
for catching disk access at that early state (13s from openSUSE start).
