[opensuse] openSUSE 10.2, desktop PC, disk being constantly written to. Any way to reduce it?
Hi all! I subscribed to this list to ask about this issue. I've not found almost any coverage on this topic, or then I've searched for wrong keywords on Google and on various mailing lists. My issues is as follows: I've recently upgraded to openSUSE 10.2 from SuSE Linux 9.3 on my desktop PC. This is no server or anything, and I'm the only user. I've noticed that at least on my upgraded installation the system seems to be almost constantly accessing through file I/O's the "/" mounted disk and also the "/home" partition. I realised this as I studied the output given by "iostat." If I leave it to monitor the system while running X and KDE, it shows constant "blocks written" action on hda, which contains both the root partition "/" and home partitions. I tried and mounted my /tmp to hdb, to see if the temp directory would be the subject of constant disk I/O (rather logical), especially while running KDE. But the /tmp partition actually shows only very limited read and write actions. If my KDE runs idle without me doing anything in particular, with some applications running such as Kontact, couple of konsoles, Firefox, couple of Konquerors, etc., the tmp sees almost no activity unless some application is operated on. Still, hda is constantly being written to. How does it show? Well, first of all, there's constantly (every few seconds) from some 8 to few dozens blocks being written, according to iostat. Almost no reading at all. Then, every so often, maybe after every 2 or 3 minutes (I'm not sure yet if this varies), it writes a bigger burst of data, one that I can easily hear the hard drive doing, and it can least a few seconds, but less than 10 seconds I'd say. This constant writing (constant writing plus regular bursts) is done irrespective to the activity of the desktop. Whether I do something or not, this happens. Even when back on pure console on run level 3. I've studied my memory utilisation. I've 512MB of RAM, and despite what "free" shows, this happen. My swap partition is on hdb, so it is not that, and it is almost always zero Kb any way. So the system is not swapping under low memory or anything. My swappiness is "60"; altering this value has no effect. And my memory utilisation (+/- buffers in cache) never seems to go below 300MB free. Anyway, as mentioned, the amount of free memory seems to have no effect on the constant writing on hda. I've searched the web to find something related to this, but have come up with nothing useful. I've closed down all unnecessary processes I know I can, but that has as little effect as anything else I try. None of the logs seem to be flooded with data, and I even turned off firewall logging. I uninstalled all Apparmor etc. stuff and even closed sshd and similar. No effect. I didn't find any way to monitor which files are constantly being written to. One command listed all open files per process, but it prints hundreds of lines, and seems to be of no use for knowing where the constant disk output is headed. So I tried to find via kfind which files have most recently been written to (access date changed to current.) There were tons of those, but at least it seems that in /sys and especially in /proc huge amount of files are updated so that they're always marked as having been updated at the same time as the current time shown by system clock. Not even a minute behind, never. Might this folder be the subject to this constant disk output? It seems it could be, or at least could be one of the culprits. All my hda partitoons were formatted for SuSE 9.3 when it was installed, and are ReiserFS. According to Yast partitioner, they seem to have been set to "ordered data mode" from the three possible (journal, ordered, writeback.) This is what was then set by default, as I don't remember to having changed those. Why is this constant I/O a problem? Well, I have a feeling my old SuSE 9.3 did not do this. What is more, I'm worried if my poor IDE hard drive can take all this strain the system is putting on it. If my hard disk is writing 24h/day, how long will it last before it dies under such server-level use? The heads need to constantly move and write... and these standard IDE HDD's are definitely no server level units that are designed to perform under constant stress. Linux being a server OS, it may not care by default about my hardware all that much. So I would definitely want to know if there was any way to make the system (Kernel?) not to write non-stop (to /proc? and/or elsewhere), and if this was a symptom of something being wrong somewhere. I've also read on the web about "laptop modes" etc. that avoid excess and unnecessary disk I/O to allow spinn-downs etc. Could something like this be employed on my desktop PC? Would there be anything in /etc/sysconfig to edit--I already even turned off all weird sounding man pages related jobs put there in "cron". And above all, do others' systems show similar disk I/O behaviour? Oh, almost forgot: I don't offer any network services etc. Not even SSH like I used to. Thank you for providing any insight you might have on this. Any kind of advice will be appreciated. I may have forgotten to mention something very elementary that I've tried or looked at, so feel free to ask if you believe I've not checked something obvious. Thank you, Tero Pesonen -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Tero Pesonen wrote:
Hi all!
I subscribed to this list to ask about this issue. I've not found almost any coverage on this topic, or then I've searched for wrong keywords on Google and on various mailing lists.
My issues is as follows: I've recently upgraded to openSUSE 10.2 from SuSE Linux 9.3 on my desktop PC. This is no server or anything, and I'm the only user.
I've noticed that at least on my upgraded installation the system seems to be almost constantly accessing through file I/O's the "/" mounted disk and also the "/home" partition. I realised this as I studied the output given by "iostat." If I leave it to monitor the system while running X and KDE, it shows constant "blocks written" action on hda, which contains both the root partition "/" and home partitions. <snip> My initial question and impression is Beagled. That is one of the first things I get rid of in 10.2+ as it occupies way too much CPU and disk resource doing its indexing. Is it running on your system? If so, does it help if you disable/remove Beagle? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, 30 Jun 2007, Richard Creighton wrote:
Tero Pesonen wrote:
Hi all!
I subscribed to this list to ask about this issue. I've not found almost any coverage on this topic, or then I've searched for wrong keywords on Google and on various mailing lists.
My issues is as follows: I've recently upgraded to openSUSE 10.2 from SuSE Linux 9.3 on my desktop PC. This is no server or anything, and I'm the only user.
I've noticed that at least on my upgraded installation the system seems to be almost constantly accessing through file I/O's the "/" mounted disk and also the "/home" partition. I realised this as I studied the output given by "iostat." If I leave it to monitor the system while running X and KDE, it shows constant "blocks written" action on hda, which contains both the root partition "/" and home partitions. <snip> My initial question and impression is Beagled. That is one of the first things I get rid of in 10.2+ as it occupies way too much CPU and disk resource doing its indexing. Is it running on your system? If so, does it help if you disable/remove Beagle?
No, nothing relating to Beagle is running according to Ksysguard. Also I'm quite sure I uninstalled it rather soon after I upgraded to openSUSE 10.2 I checked again, and "Su" -> "ps x" prints the following PID TTY STAT TIME COMMAND 1 ? Ss 0:01 init [3] 2 ? S 0:00 [migration/0] 3 ? SN 0:00 [ksoftirqd/0] 4 ? S< 0:00 [events/0] 5 ? S< 0:00 [khelper] 6 ? S< 0:00 [kthread] 9 ? S< 0:00 [kblockd/0] 10 ? S< 0:00 [kacpid] 11 ? S< 0:00 [kacpi_notify] 123 ? S< 0:00 [cqueue/0] 124 ? S< 0:00 [kseriod] 166 ? S 0:00 [pdflush] 167 ? S 0:00 [pdflush] 168 ? S< 0:00 [kswapd0] 169 ? S< 0:00 [aio/0] 418 ? S< 0:00 [kpsmoused] 832 ? S< 0:00 [reiserfs/0] 890 ? S<s 0:00 /sbin/udevd --daemon 1273 ? S< 0:00 [khubd] 2552 ? Ss 0:00 /sbin/acpid 2578 ? Ss 0:00 /sbin/resmgrd 2588 ? Ss 0:00 /usr/sbin/polkitd 2599 ? S 0:00 hald-runner 2941 ? S 0:00 hald-addon-storage: polling /dev/hdc 3298 ? Ss 0:00 /sbin/dhcpcd -C -D -K -N -t 999999 -h TP -c /etc/sysconfig/ 3619 ? Ss 0:00 /usr/sbin/famd -t 4 -T 0 -L 3648 ? Ssl 0:00 /usr/sbin/nscd 4017 tty2 Ss+ 0:00 /sbin/mingetty tty2 4021 tty3 Ss+ 0:00 /sbin/mingetty tty3 4023 tty4 Ss+ 0:00 /sbin/mingetty tty4 4024 tty5 Ss+ 0:00 /sbin/mingetty tty5 4032 tty6 Ss+ 0:00 /sbin/mingetty tty6 4070 ? S< 0:00 [kauditd] 5623 ? Ss 0:00 login -- tero 5681 tty7 Ss+ 4:36 X :0 -auth /home/tero/.serverauth.5655 -nolisten tcp -nolis 5929 ? S 0:00 /usr/sbin/powersaved -d -f /var/run/acpid.socket -v 3 6848 pts/2 S 0:00 su 6851 pts/2 S 0:00 bash 6857 pts/2 R+ 0:00 ps x -- Tero Pesonen -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun, 1 Jul 2007, Tero Pesonen wrote:
On Sat, 30 Jun 2007, Richard Creighton wrote:
Tero Pesonen wrote:
Hi all!
I subscribed to this list to ask about this issue. I've not found almost any coverage on this topic, or then I've searched for wrong keywords on Google and on various mailing lists.
My issues is as follows: I've recently upgraded to openSUSE 10.2 from SuSE Linux 9.3 on my desktop PC. This is no server or anything, and I'm the only user.
I've noticed that at least on my upgraded installation the system seems to be almost constantly accessing through file I/O's the "/" mounted disk and also the "/home" partition. I realised this as I studied the output given by "iostat." If I leave it to monitor the system while running X and KDE, it shows constant "blocks written" action on hda, which contains both the root partition "/" and home partitions. <snip> My initial question and impression is Beagled. That is one of the first things I get rid of in 10.2+ as it occupies way too much CPU and disk resource doing its indexing. Is it running on your system? If so, does it help if you disable/remove Beagle?
No, nothing relating to Beagle is running according to Ksysguard. Also I'm quite sure I uninstalled it rather soon after I upgraded to openSUSE 10.2
I checked again, and
Here's an updated listing versus my oldder post, as it is actually ps -e that shows all running processes. Looks like my typical KDE session save ksysguard and kpowersave that were now running for testing purposes. PID TTY TIME CMD 1 ? 00:00:01 init 2 ? 00:00:00 migration/0 3 ? 00:00:00 ksoftirqd/0 4 ? 00:00:00 events/0 5 ? 00:00:00 khelper 6 ? 00:00:00 kthread 9 ? 00:00:00 kblockd/0 10 ? 00:00:00 kacpid 11 ? 00:00:00 kacpi_notify 123 ? 00:00:00 cqueue/0 124 ? 00:00:00 kseriod 166 ? 00:00:00 pdflush 167 ? 00:00:00 pdflush 168 ? 00:00:00 kswapd0 169 ? 00:00:00 aio/0 418 ? 00:00:00 kpsmoused 832 ? 00:00:00 reiserfs/0 890 ? 00:00:00 udevd 1273 ? 00:00:00 khubd 2538 ? 00:00:00 dbus-daemon 2552 ? 00:00:00 acpid 2578 ? 00:00:00 resmgrd 2588 ? 00:00:00 polkitd 2598 ? 00:00:01 hald 2599 ? 00:00:00 hald-runner 2648 ? 00:00:00 hald-addon-acpi 2658 ? 00:00:00 hald-addon-keyb 2674 ? 00:00:00 hald-addon-keyb 2941 ? 00:00:00 hald-addon-stor 3298 ? 00:00:00 dhcpcd 3579 ? 00:00:00 portmap 3619 ? 00:00:00 famd 3648 ? 00:00:00 nscd 4017 tty2 00:00:00 mingetty 4021 tty3 00:00:00 mingetty 4023 tty4 00:00:00 mingetty 4024 tty5 00:00:00 mingetty 4032 tty6 00:00:00 mingetty 4070 ? 00:00:00 kauditd 5623 ? 00:00:00 login 5635 tty1 00:00:00 bash 5655 tty1 00:00:00 startx 5656 tty1 00:00:00 tee 5680 tty1 00:00:00 xinit 5681 tty7 00:05:03 X 5686 tty1 00:00:00 kde 5698 ? 00:00:00 dbus-daemon 5699 tty1 00:00:00 dbus-launch 5734 tty1 00:00:00 start_kdeinit 5735 ? 00:00:00 kdeinit 5738 ? 00:00:00 dcopserver 5740 ? 00:00:00 klauncher 5742 ? 00:00:04 kded 5747 tty1 00:00:00 kwrapper 5749 ? 00:00:00 ksmserver 5750 ? 00:00:03 kwin 5752 ? 00:00:05 kdesktop 5754 ? 00:00:00 kio_file 5755 ? 00:00:06 kicker 5794 ? 00:00:00 knotes 5797 ? 00:00:00 kdesud 5929 ? 00:00:00 powersaved 5972 ? 00:00:00 knotify 5976 ? 00:00:00 gconfd-2 5979 ? 00:00:00 firefox 5982 ? 00:00:00 run-mozilla.sh 5987 ? 00:02:00 firefox-bin 6037 ? 00:00:00 kpowersave 6040 ? 00:00:19 konqueror 6178 ? 00:00:09 konsole 6179 pts/1 00:00:02 pine 6471 ? 00:00:01 konsole 6472 pts/2 00:00:00 bash 6842 ? 00:00:13 ksysguard 6843 ? 00:00:07 ksysguardd 6848 pts/2 00:00:00 su 6851 pts/2 00:00:00 bash 6882 pts/2 00:00:00 ps -- Tero Pesonen -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun, 2007-07-01 at 02:01 +0300, Tero Pesonen wrote:
On Sun, 1 Jul 2007, Tero Pesonen wrote:
On Sat, 30 Jun 2007, Richard Creighton wrote:
<snip>
No, nothing relating to Beagle is running according to Ksysguard. Also I'm quite sure I uninstalled it rather soon after I upgraded to openSUSE 10.2
I checked again, and
Here's an updated listing versus my oldder post, as it is actually ps -e that shows all running processes. Looks like my typical KDE session save ksysguard and kpowersave that were now running for testing purposes.
PID TTY TIME CMD 1 ? 00:00:01 init 2 ? 00:00:00 migration/0 3 ? 00:00:00 ksoftirqd/0 4 ? 00:00:00 events/0 <snip> You might also try running top to see what might be hogging the CPU/IO usage.
-- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Saturday 30 June 2007 15:16, Tero Pesonen wrote:
Hi all!
...
I've noticed that at least on my upgraded installation the system seems to be almost constantly accessing through file I/O's the "/" mounted disk and also the "/home" partition. I realised this as I studied the output given by "iostat." If I leave it to monitor the system while running X and KDE, it shows constant "blocks written" action on hda, which contains both the root partition "/" and home partitions.
It may just be the updatedb process, which indexes all known files so you can find them by name (or name fragment or pattern).
...
How does it show? Well, first of all, there's constantly (every few seconds) from some 8 to few dozens blocks being written, according to iostat. ...
You do realize, don't you, that this is really just a trickle of data. If your system were busy doing things you thought were important (perhaps a complex query or update on a large database), the presence or absence of this additional I/O volume would go entirely unnoticed and be unmeasurable against such an application load.
This constant writing (constant writing plus regular bursts) is done irrespective to the activity of the desktop. Whether I do something or not, this happens. Even when back on pure console on run level 3.
...
So I tried to find via kfind which files have most recently been written to (access date changed to current.) There were tons of those, but at least it seems that in /sys and especially in /proc huge amount of files are updated so that they're always marked as having been updated at the same time as the current time shown by system clock. Not even a minute behind, never.
Try to think of it as really fresh data. Like really fresh food. ... Or whatever it takes to change your worry into calmness...
Might this folder be the subject to this constant disk output? It seems it could be, or at least could be one of the culprits.
All my hda partitoons were formatted for SuSE 9.3 when it was installed, and are ReiserFS. According to Yast partitioner, they seem to have been set to "ordered data mode" from the three possible (journal, ordered, writeback.) This is what was then set by default, as I don't remember to having changed those.
Why is this constant I/O a problem?
Only because you've become aware of it, I'd say.
Well, I have a feeling my old SuSE 9.3 did not do this. What is more, I'm worried if my poor IDE hard drive can take all this strain the system is putting on it.
Strain? Hardly! Try not to think of it as someone barking orders at you, wearing you down and exhausting your. Computer hardware really isn't like a biological organism.
If my hard disk is writing 24h/day, how long will it last before it dies under such server-level use?
Evidently you don't know what constitutes "server-level" use! Servers will sustain _continuous_ loads near their rated maximum for hours and hours on end! What you've described is nothing like that level of load.
The heads need to constantly move and write... and these standard IDE HDD's are definitely no server level units that are designed to perform under constant stress.
The best thing to do is to refrain from anthropomorphizing computer hardware!
...
And above all, do others' systems show similar disk I/O behaviour?
Yes. All Linux systems are logging all the time. They do daily bookkeeping, which for systems that are not kept on 24 hours per day, will happen as soon as they're started up each day. Computers are rarely quiescent in any literal sense. They're always doing things. That's why we have them!
...
Thank you, Tero Pesonen
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Thank you both Kenneth and Randall for your input. I've quoted below. Nothing important any more on this matter, though. On Sat, 30 Jun 2007, Randall R Schulz wrote:
On Saturday 30 June 2007 15:16, Tero Pesonen wrote:
Hi all!
...
I've noticed that at least on my upgraded installation the system seems to be almost constantly accessing through file I/O's the "/" mounted disk and also the "/home" partition. I realised this as I studied the output given by "iostat." If I leave it to monitor the system while running X and KDE, it shows constant "blocks written" action on hda, which contains both the root partition "/" and home partitions.
It may just be the updatedb process, which indexes all known files so you can find them by name (or name fragment or pattern).
I also considered something like this, but eventually went down, as suggested earlier to me off-list, to minimum level of running processes through Yast services per run level editor. This didn't have any effect on the constant writing at the time, so I simply shut down for the night. Today, I booted and realized that at least so far it seems that disk access is greatly reduced. If I'm not doing something, the systems isn't writing fevorously, but only writes a few hundred blocks per a ten second period. Seems and sounds more like the way things were on SuSE 9.3 (and 8.2 before it) based on my not-so-scientific listen-with-an-ear meter.
...
How does it show? Well, first of all, there's constantly (every few seconds) from some 8 to few dozens blocks being written, according to iostat. ...
You do realize, don't you, that this is really just a trickle of data. If your system were busy doing things you thought were important (perhaps a complex query or update on a large database), the presence or absence of this additional I/O volume would go entirely unnoticed and be unmeasurable against such an application load.
Of course. This is/was not a performance issue. Rather, I was worried if there was something fishy going on--something wrong with my setup. Well, there wasn't.
This constant writing (constant writing plus regular bursts) is done irrespective to the activity of the desktop. Whether I do something or not, this happens. Even when back on pure console on run level 3.
...
So I tried to find via kfind which files have most recently been written to (access date changed to current.) There were tons of those, but at least it seems that in /sys and especially in /proc huge amount of files are updated so that they're always marked as having been updated at the same time as the current time shown by system clock. Not even a minute behind, never.
Try to think of it as really fresh data. Like really fresh food. ... Or whatever it takes to change your worry into calmness...
Well, I was thinking of it more as unnecessarily produced junk food than fresh food per se, but from now on I will adopt that view. After all, from the operating system's point of view, no data or task is useless if it is being done.
Might this folder be the subject to this constant disk output? It seems it could be, or at least could be one of the culprits.
All my hda partitions were formatted for SuSE 9.3 when it was installed, and are ReiserFS. According to Yast partitioner, they seem to have been set to "ordered data mode" from the three possible (journal, ordered, writeback.) This is what was then set by default, as I don't remember to having changed those.
Why is this constant I/O a problem?
Only because you've become aware of it, I'd say.
That's probably it. And now it's down any way, after shutting down anything unnecessary as mentioned earlier. Which may not be all that bad thing to have come to pass, so to say, considering that I've never seen such free +- buffers/cache numbers upon system start-up as I did today. Which means more memory for Firefox to hog and eat away.
Well, I have a feeling my old SuSE 9.3 did not do this. What is more, I'm worried if my poor IDE hard drive can take all this strain the system is putting on it.
Strain? Hardly! Try not to think of it as someone barking orders at you, wearing you down and exhausting your. Computer hardware really isn't like a biological organism.
OK, ok... "strain" wasn't perhaps the most spot-on English word to choose, nor was it very technical to refer to a piece of electronics as "poor." My HDD's are poor only in the sense that they've been put together from the cheapest possible components to guarantee (on average) a certain expected life span under average home PC use, so as to make it financially feasible for Seagate to grant them a certain kind of warranty period. And no, I don't believe there's a hard-working gnome living under my desk or anything... one whose back could break under excess "strain." :)
If my hard disk is writing 24h/day, how long will it last before it dies under such server-level use?
Evidently you don't know what constitutes "server-level" use!
No, of course I didn't mean it literally.
Servers will sustain _continuous_ loads near their rated maximum for hours and hours on end! What you've described is nothing like that level of load.
The heads need to constantly move and write... and these standard IDE HDD's are definitely no server level units that are designed to perform under constant stress.
The best thing to do is to refrain from anthropomorphizing computer hardware!
I needed a dictionary for that word of your's. Yes, I shall refrain from anthropo... well gnomemizing.
...
And above all, do others' systems show similar disk I/O behaviour?
Yes. All Linux systems are logging all the time. They do daily bookkeeping, which for systems that are not kept on 24 hours per day, will happen as soon as they're started up each day. Computers are rarely quiescent in any literal sense. They're always doing things. That's why we have them!
Yes. Thanks for your comments. There's even a new English word for me, "quiescent." -- Tero Pesonen -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2007-07-01 at 01:16 +0300, Tero Pesonen wrote: ...
How does it show? Well, first of all, there's constantly (every few seconds) from some 8 to few dozens blocks being written, according to iostat. Almost no reading at all. Then, every so often, maybe after every 2 or 3 minutes (I'm not sure yet if this varies), it writes a bigger burst of data, one that I can easily hear the hard drive doing, and it can least a few seconds, but less than 10 seconds I'd say.
Have a look at variables like ACPI_THROTTLED_KUPDATED_INTERVAL in /etc/sysconfig/powermanagement. I think there are more of the sort.
I didn't find any way to monitor which files are constantly being written to.
A pity.
So I tried to find via kfind which files have most recently been written to (access date changed to current.) There were tons of those, but at least it seems that in /sys and especially in /proc huge amount of files are updated so that they're always marked as having been updated at the same time as the current time shown by system clock. Not even a minute behind, never.
However, those two folders hold "virtual" files, so they can't be affecting.
All my hda partitoons were formatted for SuSE 9.3 when it was installed, and are ReiserFS. According to Yast partitioner, they seem to have been set to "ordered data mode" from the three possible (journal, ordered, writeback.) This is what was then set by default, as I don't remember to having changed those.
Add options "noatime,nodiratime" to your fstab file. Every time a file is read, the time when it is read is written to the filesystem, causing activity. I'm also thinking of /proc and /sys dirs: they files are virtual, but the directories themselves are physical, and therefore, their 'atimes" are written to the HD.
Why is this constant I/O a problem? Well, I have a feeling my old SuSE 9.3 did not do this. What is more, I'm worried if my poor IDE hard drive can take all this strain the system is putting on it. If my hard disk is writing 24h/day, how long will it last before it dies under such server-level use? The heads need to constantly move and write... and these standard IDE HDD's are definitely no server level units that are designed to perform under constant stress.
Well, the disk will certainly not go to sleep, but I have noticed this behaviour ever since I started using linux. Windows did not behave this way (3.11 at the time): I noticed my disk went to sleep because I had to wait for it to wake up a few seconds after 20 minutes of not using the computer. This doesn't happen with the disk holding "/" in linux, but it might happen with data disks.
I've also read on the web about "laptop modes" etc. that avoid excess and unnecessary disk I/O to allow spinn-downs etc. Could something like this be employed on my desktop PC?
Yes, probably.
Would there be anything in /etc/sysconfig to edit--I already even turned off all weird sounding man pages related jobs put there in "cron".
I don't think cron will have much effect. But yes, there are settings in the file I mentioned, and maybe in /etc/sysconfig/powersave/disk. Probably better to use yast to adjust those - not quite, not all settings are accesible. You can even add a scheme, and it will be created in that dir, where you can further fine tune it.
And above all, do others' systems show similar disk I/O behaviour?
Yes. I haven't manage to discover "who" is the culprit, but yes.
Oh, almost forgot: I don't offer any network services etc. Not even SSH like I used to.
Don't forget log entries... - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGh4w8tTMYHG2NR9URAlsAAKCQfGBkV7cLiN/Gi/BNwZDccOpYaQCfRRd1 WrRVJNg4U0TsCeirRJrc22Q= =QSNM -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun, 1 Jul 2007, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Sunday 2007-07-01 at 01:16 +0300, Tero Pesonen wrote:
...
How does it show? Well, first of all, there's constantly (every few seconds) from some 8 to few dozens blocks being written, according to iostat. Almost no reading at all. Then, every so often, maybe after every 2 or 3 minutes (I'm not sure yet if this varies), it writes a bigger burst of data, one that I can easily hear the hard drive doing, and it can least a few seconds, but less than 10 seconds I'd say.
Have a look at variables like ACPI_THROTTLED_KUPDATED_INTERVAL in /etc/sysconfig/powermanagement. I think there are more of the sort.
In my earlier reply to this list I considered this issue as mostly solved for what I think is "normal." I also fiddled with the powersave settings through Yast and asked it to set the "powersave" mode as the default. That probably had some effect. Also, I turned off each and every process I do not need. Both or either one of these made some real difference.
I didn't find any way to monitor which files are constantly being written to.
A pity.
So I tried to find via kfind which files have most recently been written to (access date changed to current.) There were tons of those, but at least it seems that in /sys and especially in /proc huge amount of files are updated so that they're always marked as having been updated at the same time as the current time shown by system clock. Not even a minute behind, never.
However, those two folders hold "virtual" files, so they can't be affecting.
OK.
All my hda partitoons were formatted for SuSE 9.3 when it was installed, and are ReiserFS. According to Yast partitioner, they seem to have been set to "ordered data mode" from the three possible (journal, ordered, writeback.) This is what was then set by default, as I don't remember to having changed those.
Add options "noatime,nodiratime" to your fstab file. Every time a file is read, the time when it is read is written to the filesystem, causing activity. I'm also thinking of /proc and /sys dirs: they files are virtual, but the directories themselves are physical, and therefore, their 'atimes" are written to the HD.
I had already added the option noatime, which actually might have helped a bit. I will still add nodirtime, although my system seems to run already quite well. At least the blocks read/written ratio is more even than it used to be and the tps number is much lower overall and what is more, it remains low during inactivity and there are no regular large "bursts" of data any more.
Why is this constant I/O a problem? Well, I have a feeling my old SuSE 9.3 did not do this. What is more, I'm worried if my poor IDE hard drive can take all this strain the system is putting on it. If my hard disk is writing 24h/day, how long will it last before it dies under such server-level use? The heads need to constantly move and write... and these standard IDE HDD's are definitely no server level units that are designed to perform under constant stress.
Well, the disk will certainly not go to sleep, but I have noticed this behaviour ever since I started using linux. Windows did not behave this way (3.11 at the time): I noticed my disk went to sleep because I had to wait for it to wake up a few seconds after 20 minutes of not using the computer. This doesn't happen with the disk holding "/" in linux, but it might happen with data disks.
I've also read on the web about "laptop modes" etc. that avoid excess and unnecessary disk I/O to allow spinn-downs etc. Could something like this be employed on my desktop PC?
Yes, probably.
I think the "Powersave" named power saving mode already does something like this. But not sure. Any way, things seem better now.
Would there be anything in /etc/sysconfig to edit--I already even turned off all weird sounding man pages related jobs put there in "cron".
I don't think cron will have much effect. But yes, there are settings in the file I mentioned, and maybe in /etc/sysconfig/powersave/disk. Probably better to use yast to adjust those - not quite, not all settings are accesible. You can even add a scheme, and it will be created in that dir, where you can further fine tune it.
I may still take a look at those, but if I'm happy how things are now I think I won't go fiddling with those certain disk settings that if done wrong, could have undesirable side effects, even data loss, as has been warned on the web.
And above all, do others' systems show similar disk I/O behaviour?
Yes. I haven't manage to discover "who" is the culprit, but yes.
Oh, almost forgot: I don't offer any network services etc. Not even SSH like I used to.
Don't forget log entries...
Yes, I also checked them, but none was flooded with data nor were there recurring warnings or errors or anything of particular interest. I would consider this mostly solved for as far as I dare to go without making anything too risky. I've used Linux since SuSE 8.2, so I should already know not to expect things to work as they do on Windows. Thanks, Tero Pesonen -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2007-07-01 at 15:33 +0300, Tero Pesonen wrote: ...
Don't forget log entries...
Yes, I also checked them, but none was flooded with data nor were there recurring warnings or errors or anything of particular interest.
Notice that simply by watching the log you may cause a periodic write operation: every read means a write of the access time. That's why it is important to dissable it. For instance "tail -f file" causes continuous writes, but "tailf file" does not. This is documented somewhere.
I would consider this mostly solved for as far as I dare to go without making anything too risky. I've used Linux since SuSE 8.2, so I should already know not to expect things to work as they do on Windows.
Still, letting the disks go to sleep is a good thing, IMO. This "should" work. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGh78TtTMYHG2NR9URAunBAKCCPjotdm10UssIQEaOJ429CPlIBQCfT6eq vC/mSD/RcXPSJMWRUolwF1c= =Ji2T -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun, 1 Jul 2007, Carlos E. R. wrote:
Don't forget log entries...
Yes, I also checked them, but none was flooded with data nor were there recurring warnings or errors or anything of particular interest.
Notice that simply by watching the log you may cause a periodic write operation: every read means a write of the access time. That's why it is important to dissable it.
For instance "tail -f file" causes continuous writes, but "tailf file" does not. This is documented somewhere.
I would consider this mostly solved for as far as I dare to go without making anything too risky. I've used Linux since SuSE 8.2, so I should already know not to expect things to work as they do on Windows.
Still, letting the disks go to sleep is a good thing, IMO. This "should" work.
I've never managed to get any of the standby modes to work. I've tried using KPowersave on KDE, but asking it to initialise standby mode only causes the system to hard crash: It gets totally jummed after having suspended processes, and cannot be recovered without forcing a hard reboot via the motherboard. Simply commanding a disk to go to standby with hdparm (-y or -Y) spinns them down, but only to be waken up in a minute or so as some data needs to be written. On the other hand, I haven't really researched this, as I nowadays shut down for the night. If standby worked, I wouldn't have to do that, of course. I don't care to try too much, though, as such a hard crash causes some heavy file system check runs on reboot and even forced me to boot on failsafe before I was able to boot normally again. (Normal boot didn't proceed past a certain point, but it was easily fixed.) So I don't want to have those crashes to happen and risk more and more serious problems arising as a result. It would be interesting to try to have the standby work, yes, but trying it out when it doesn't work seems too dangerous. And I mean it really crashes: I tried to SSH to my machine from another one, so as to log in and try and get it up again, but SSH simply timed out, as obviously SSHD, and perhpas the network interface too, had been suspended. Is there any other way to initialise standby than via KPowersave? I wonder if the problem lies in KDE or X. It would be no problem at all if I had to exit KDE and X for standby in case I happened to know I'd be leaving the machine running idle for a couple of hours, or would leave it on for the night so as to avoid daily hard boots. I boot to runlevel 3, then manually start KDE, so I need not init 3 or anything to get out of X. -- Tero Pesonen -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2007-07-01 at 19:13 +0300, Tero Pesonen wrote:
Still, letting the disks go to sleep is a good thing, IMO. This "should" work.
I've never managed to get any of the standby modes to work. I've tried using KPowersave on KDE, but asking it to initialise standby mode only causes the system to hard crash: It gets totally jummed after having suspended processes, and cannot be recovered without forcing a hard reboot via the motherboard.
Ah, you mean suspend to disk, or hibernating. I was thinking simply of spinning down a disk, but I have only succeeded with auxiliary disks, not the one holding root. On the other hand, I routinely hibernate my computer to disk, instead of halting the computer to power it off. It works very well for me, and it is way faster than halting/booting.
Is there any other way to initialise standby than via KPowersave? I wonder if the problem lies in KDE or X. It would be no problem at all if I had to exit KDE and X for standby in case I happened to know I'd be leaving the machine running idle for a couple of hours, or would leave it on for the night so as to avoid daily hard boots. I boot to runlevel 3, then manually start KDE, so I need not init 3 or anything to get out of X.
I use gnome, so no kpowersave. I suspend by touching the power button (holding it for 4" powers off hard). There is also a command to suspend from the kernel (powersave -U), but it may cause problems as it doesn't do other things needed before suspending. There are many options you can change related to this: use the bios, the kernel, unload modules, stop services... its a kind of black art. I'm not sure which files hold the configs, things have changed recently, and I have a very mixed mix. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGiD3mtTMYHG2NR9URAirgAJ4g2Dt0zUYreFsbumVpSa+j2GC8RQCfVjeb r5Md4guhOAVdsz2uItuEzkE= =cJpg -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Mon, 2 Jul 2007, Carlos E. R. wrote:
Still, letting the disks go to sleep is a good thing, IMO. This "should" work.
I've never managed to get any of the standby modes to work. I've tried using KPowersave on KDE, but asking it to initialise standby mode only causes the system to hard crash: It gets totally jummed after having suspended processes, and cannot be recovered without forcing a hard reboot via the motherboard.
Ah, you mean suspend to disk, or hibernating. I was thinking simply of spinning down a disk, but I have only succeeded with auxiliary disks, not the one holding root.
On the other hand, I routinely hibernate my computer to disk, instead of halting the computer to power it off. It works very well for me, and it is way faster than halting/booting.
Is there any other way to initialise standby than via KPowersave? I wonder if the problem lies in KDE or X. It would be no problem at all if I had to exit KDE and X for standby in case I happened to know I'd be leaving the machine running idle for a couple of hours, or would leave it on for the night so as to avoid daily hard boots. I boot to runlevel 3, then manually start KDE, so I need not init 3 or anything to get out of X.
I use gnome, so no kpowersave. I suspend by touching the power button (holding it for 4" powers off hard). There is also a command to suspend from the kernel (powersave -U), but it may cause problems as it doesn't do other things needed before suspending.
There are many options you can change related to this: use the bios, the kernel, unload modules, stop services... its a kind of black art. I'm not sure which files hold the configs, things have changed recently, and I have a very mixed mix.
OK, thanks for your reply. I'll be away for some time on a trip, but I think I'll have a look at this when I'm back. If something interesting turns up I'll return to this topic on this list. Tero Pesonen -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun, July 1, 2007 4:51 pm, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Sunday 2007-07-01 at 19:13 +0300, Tero Pesonen wrote:
Still, letting the disks go to sleep is a good thing, IMO. This "should" work.
I've never managed to get any of the standby modes to work. I've tried using KPowersave on KDE, but asking it to initialise standby mode only causes the system to hard crash: It gets totally jummed after having suspended processes, and cannot be recovered without forcing a hard reboot via the motherboard.
Ah, you mean suspend to disk, or hibernating. I was thinking simply of spinning down a disk, but I have only succeeded with auxiliary disks, not the one holding root.
On the other hand, I routinely hibernate my computer to disk, instead of halting the computer to power it off. It works very well for me, and it is way faster than halting/booting.
I kinda missed who wrote what about this function, but IIRC, I would have consistent crashes of the filing system (reiser) under 9.3 when suspending to disk and trying to resume. These problems went away in 10.0 and have not been present at all in 10.2. I suspend my laptops to disk on a routine basis and have yet to see an issue. -- ka -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2007-07-02 at 14:10 -0700, Kai Ponte wrote: [hibernating to disk]
I kinda missed who wrote what about this function, but IIRC, I would have consistent crashes of the filing system (reiser) under 9.3 when suspending to disk and trying to resume.
These problems went away in 10.0 and have not been present at all in 10.2. I suspend my laptops to disk on a routine basis and have yet to see an issue.
I have one: If I leave a usb keyring type flash disk, formatted as vfat, I can't use it again when returning. It is not mounted, but it seems part of the system thinks it is, so it can neither be umounted nor mounted. Possibly the awakening script tries to remount it before it becomes available, or the other way round. I still have to verify this. The rest of fat partitions on HD do not pose a problem. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGiXxdtTMYHG2NR9URArgNAJ4z/yjMvOw1615mCMigrcOTBoOb8gCdHeHX zdAdmoJHL5Qgmi/+Vczx+qg= =Miaw -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sun, Jul 01, 2007 at 01:16:00AM +0300, Tero Pesonen wrote:
I've noticed that at least on my upgraded installation the system seems to be almost constantly accessing through file I/O's the "/" mounted disk and
Suggest you investigate powertop program, from our friends at Intel: http://www.linuxpowertop.org/ It requires a recompiled kernel (I seem to recall hearing there is an openSUSE build service kernel with the necessary support for powertop), and the overhead makes it enough that you may not want to run with it on full-time, but it can help you find offenders.
with nothing useful. I've closed down all unnecessary processes I know I can, but that has as little effect as anything else I try. None of the logs seem to be flooded with data, and I even turned off firewall logging. I uninstalled all Apparmor etc. stuff and even closed sshd and similar. No effect.
AppArmor logs events in two cases: o the event fails security policy -or- o you have a profile in learning mode, and the profile performs some forks, execs, etc. (This information is used to construct intelligent questions to prompt the user later.) This logging can be pretty intense :) so we don't recommend leaving profiles on production systems in complain mode longer than necessary. :) Hope this helps
participants (7)
-
Carlos E. R. -
Kai Ponte -
Kenneth Schneider -
Randall R Schulz -
Richard Creighton -
Seth Arnold -
Tero Pesonen