Spurious disk activity

I have AAO 110 (8GB SSD, 1.5Gb RAM) with UNR 9.04 loaded. When booting up the UNR desktop appears and the system looks ready for use, but after another 10 seconds the hard disk LED will light up and stay on for about 25 seconds. The system will not respond during this time.

Is there a disk activity monitor for Linux that would show what the disk is doing ?

I thought I had fixed this when I reloaded UNR last week but its still the same.

 

Disable "D2D Recovery" in the BIOS.

 

I have disabled D2D but it's still the same. Seems to be a bit like Windows, the desktop appears but the system is not yet ready for use.

 

I've got exactly the same issue which has only cropped up since the Kernel update on Friday. Upon the update asking to replace my original menu.lst I opted to keep it knowing I'd made modifications for the SSD and Video - could this be related?

 

I have had this problem for a few weeks, before I reloaded the system and updates. I even tried the Kuki kernel but it made no difference. I am thinking that it may be something to do with the ext2 file system. When I first loaded UNR in April I used ext3. I don't remember having this problem with ext3 but the system became unbearably slow so I reloaded with ext2. The system is now quite fast, but this 25 second pause is annoying. I'm still looking for a disk activity monitor for Linux.

 

I think I have fixed it. I added these lines to /etc/fstab.

tmpfs /var/log tmpfs defaults 0 0
tmpfs /tmp tmpfs defaults 0 0
tmpfs /var/tmp tmpfs defaults 0 0

 

There are a number of things you can do to fix this. I've been trying to tackle that problem for a long time.

I am now testing the following parameters for ~2h and they seem to work ok.

I am preparing a major post on my blog explaining what these things do, but it's fairly complex and I haven't had the patience. If you are interesting, you can find out what they do by googling them.

Warning first. In the case of an unclean shutdown you will experience severe data loss. Be very carefull with this.

Edit sysctl.conf with something like

sudo gedit /etc/sysctl.conf

At the end of the file add these lines

#get pdflush undercontrol
vm.dirty_ratio = 70
vm.dirty_background_ratio = 3
vm.dirty_writeback_centisecs = 60000
#avoid sending things to swap
vm.swappiness=2

Directly copy pasted from mine.

 

Am I correct to infer that making these changes to sysctl.conf increases the risk of severe data loss in the event of an unexpected shutdown? If so, for me, the extra speed isn't worth the risk.

 

The biggest improvement I found was when I put the log files on Ramdisks. The 25 second pause after the desktop appeared was almost eliminated. Note that my AA0 has an SSD not an HDD.

I found that OpenDNS also makes a big improvement to browsing speed.

My system is now quite speedy, I'm happy with it now.

 

So adding these lines to etc/fstab was all that was required to do that?

Code:

tmpfs     /var/log     tmpfs    defaults   0 0
tmpfs     /tmp         tmpfs    defaults   0 0
tmpfs     /var/tmp     tmpfs    defaults   0 0

Linux/Unix is like an onion, and I'm still in the outer layers. Having read a little about fstab, if I understand these changes correctly, they define tmpfs as the mount point for these three filesystems, and ignore dump and fsck. Are there any downsides related to reliability/recoverability from these changes? In my experience, changes that speed things up generally have a cost, or to use an old axiom, you can have fast, cheap, or good -- pick any two.

I didn't notice any differences in performance after making this change, but I did notice that System Monitor, which I run in the bottom panel, was reduced from a small window to a line. So, not seeing any benefit to this change, I have backed it out.

 

Creating tmpfs for the log files will only help if you have an SSD, not an HDD. I have not had any problems with reliability, but I only use this netbook for browsing so data loss is not an issue.

 

Thanks for the clarification.

 

libssd,

The only precaution you need to have with the settings I wrote is to make sure you have the batery always hooked up, you never know when the power cable is gonna unplug by mistake. In case of a severe crash you can always change to a console and shutdown the computer manually. As I'm sure you know, a desktop crash is a very rare thing, so in practice you will barely have any problems. The performance difference is quite big, give a test, I find it very worthy.

On logs and tmpfs, I would recommend turning off the log services all together. You can do it on admnistration->services.

For future reference, the settings I wrote are giving me much less freezing, but much longer when it happens. I'm reverting to the originals I found on the ubuntu forums, but they're still not perfect. If anyone could play with these settings and find the ideal ones It would be killer.

vm.dirty_ratio = 40
vm.dirty_background_ratio = 1
vm.dirty_writeback_centisecs = 30000
vm.swappiness=10

 

Thanks for the tip, but after reading man pages for klogd and sysklogd, I think I'm going to leave them enabled. As far as I am concerned, speed is just fine on a D150.

 

One more thing about running System Monitor in the lower panel is that it provides a constant graphical representation of processor activity. Occasionally Unix processes start chewing up resources, and this gives you a heads up that this may be happening. Right-click on the small sysmon window in the panel to set preferences; I have mine to display two separate windows for processor and memory utilization -- when either window shows no black (free), it's time to look for causes. Open System Monitor to see what's going on, and kill the process (if you feel confident about that) or just reboot.

In my experience, Linux is far less likely to need rebooting than Windows, but it is necessary occasionally. FireFox, much as I love it, is a major resource hog, as it doesn't release memory that it has used, and gradually starts to eat up everything that is available, which will eventually lead to paging. I've found this to be true with Linux, MacOS, and Windows.

 

The down side of those changes is that your logs are mounted in RAM, so if you are having a problem, and wanting to debug the kernel (or other messages) or wanting to perform forensics on a cracked system, you will loose the logs when you reboot.

These changes will NOT make your system feel or run faster, they will reduce the wear and tear on your hard drive (less writes to the logs and /tmp allows your hard drive to spin down. Less writes to an internal solid state drive = less wear on the drive as well, they only have so many writes).

You may achieve *some* performance boot by mounting other temp files in RAM such as your firefox cache.

These kind of alterations to your system config will make modest performance enhancements at best.

The biggest boost you will get are :

1. Install the proper video and wireless drivers (if needed).

2. Reduce the swapiness. Unless you are low on RAM , use your ram before swap (swap space is on the HD and is two orders of magnitude slower then RAM).

3. Do not use ext3. Use either ext2 or ext4 , both of which will give you a modest but noticeable improvement.

4. Use light weight applications. for example use gedit rather then openoffice. There are light weight browsers such as dillo in place of firefox. Light weight apps do not have the bells and whistles, but the trade off is speed.

5. Light weight window managers such a Fluxbox, LXDE, Openbox, and ICEwm help as well.

 

As I pointed out earlier, mounting the log files in RAM is only recommended for SSD drives, as it has no effect with conventional hard drives. It does help to eradicate the long pauses when logs are being written to slow SSD drives.

 

That is not true. You will see a performance improvement when writing logs and other temp files with a conventional HD as well (ram is much much fasterh then a conventional hard drive).

In addition wirting logs to tmpfs (ram) allows your conventional HD to spin down as the logs are not being written every fe minutes == less power consumption and less wear and tear on the HD.

Last if you mount your firefox cache in tmpfs it speeds up firefox.

So although it is a bit of a "power teak" it benefits conventional HD , powere user, and performance.

See also : http://blog.bodhizazen.net/linux/netbook-optimization/

 

Actually, it will. Provided the system is slow/unresponsive due to SSD writes that is. In this case it will make a huge difference.

 

Actually, it will. Provided the system is slow/unresponsive due to SSD writes that is. In this case it will make a huge difference.[/quote:3kzrx6jm]

That is true, but your system should not normally be writing *that* much to the tmp or log files such that the system is slow.

It certainly can improve performance if you mount your firefox cache, for example, in ram (tmpfs).