Very slow SDD/HDD performance

[jazzgossen]

Now I have moved /var to the SSD, and at the moment things are blazing. However, as I mentioned in my original post, the problem with slow IO performance only happened sometimes, not all the time. So I don't dare to consider the problem solved just yet.

Regarding the /tmp mount point: yes, that was done manually. I wanted to move both /var and /tmp away from the SSD, to reduce the amount of writes to it. I hope putting /var back on the SSD won't kill it prematurely.

[dabl]

My main OS (debian sid) has been running on a SSD (OCZ RevoDrive) for over 2 years, including /var, and there are no signs of SSD wear issues -- this desktop runs 24/7 and only gets rebooted for new kernels. I also mount /tmp on a tmpfs, as well as /var/spool. You can mount /var/log on a tmpfs, but you'll lose your logs every reboot, so ......

[Impavidus]

It seems it's actually allowed to put /var on a different partition: http://refspecs.linuxfoundation.org/...ROOTFILESYSTEM

If I'm not mistaken SSD wear depends on the number of erase cycles, not the number of writes. Only once in every so many lines written to a log (depending on the physical block size of the drive) one block is erased, whilst normal updates erase many blocks simultaniously.

[dabl]

Yes it's perfectly "legal" to mount /var on its own partition, however for home/single user PCs that is not a commonly-needed configuration. There is some issue with the OP's system in which it appears to get into a thrashing or cache-reading mode for ridiculous periods of time, so we may learn something by going back to a simpler and more conventional configuration. (Or we may not ....).

[jazzgossen]

Now I have suspended and resumed the laptop once, and I'm back to the old behaviour again. So it might be something with suspend/hibernate rather than the partitioning? Though I don't understand how.

I know that SSD partitions also must be aligned the right way. Just to double-check, here's the output of fdisk

> sudo fdisk -lu /dev/sdb

Disk /dev/sdb: 128.0 GB, 128035676160 bytes
255 heads, 63 sectors/track, 15566 cylinders, total 250069680 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x9409c39e

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1              63       80324       40131   de  Dell Utility
/dev/sdb2   *       81920    21676031    10797056    7  HPFS/NTFS/exFAT
/dev/sdb3        21676032   134957281    56640625    7  HPFS/NTFS/exFAT
/dev/sdb4       134959102   250068991    57554945    5  Extended
/dev/sdb5       134959104   250068991    57554944   83  Linux

The root partition is on /dev/sdb5, and that partition starts on a number that is divisible by 2048, which is as it should, as far as I know. Some of the other (default Dell) partitions are not aligned that way, but that shouldn't matter, should it?

[dabl]

Right -- that first partition is not aligned, but I don't see why that would have any influence on the Linux system's performance, and the first partition should rarely if ever experience an erase operation, so ......

Hmmmm. I wonder if the tmpfs filesystems survive a suspend/resume cycle with all data intact? Or if the suspend operation interferes with the tmpfs filesystems which are also in memory? I don't use suspend on my desktop system so I don't know whether that could cause an issue with the filesystems that are mounted as tmpfs. It would interesting to know whether you have the thrashing problem at any time during an extended uptime, or whether it only crops up after resuming from suspend.

[jazzgossen]

It's definitely related to suspend. I did a reboot this morning, this time with also /tmp monted on the SSD. Everything worked fine for 2.5 hours until I suspended. Now that I have resumed, the slowness problem is back.

Another observation is that also kwin is slower after suspend/resume. Slower as in high latency. There is a lag of about one second; for example, between me pressing alt-tab and the window list appearing. Similarly, when hovering the mouse over an entry in the task bar, it takes a second or two until the thumbnail image of that window is displayed.

My problem seems to be trickier than I thought...

[jazzgossen]

I'm going through the log files, trying to see if there's any indication there of what is happening when suspending and resuming. One error that always comes up is in kern.log

PM: Device 00:0a failed to resume: error -19

There's a post in the LinuxQuestions forum about this error message here. I tried the suggestion of listing the PCI devices with "lspci -vt", but the output does not mention a device 00:0a.

[jazzgossen]

I'll keep using this thread to document my trouble shooting, in the hope that it will be helpful in the future.

Regarding the 00:0a device, that seems to be a PS/2 controller. "dmesg | grep 00:0a" outputs

> dmesg |grep 00:0a
[    0.572736] pnp 00:0a: [io  0x0060]
[    0.572738] pnp 00:0a: [io  0x0064]
[    0.572742] pnp 00:0a: [irq 1]
[    0.572776] pnp 00:0a: Plug and Play ACPI device, IDs PNP0303 (active)
[ 3798.386502] PM: Device 00:0a failed to restore: error -19

and looking for that PNP0303, I get

> dmesg |grep PNP0303
[    0.572776] pnp 00:0a: Plug and Play ACPI device, IDs PNP0303 (active)
[    1.064892] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12

I've looked around a little to see if I can just disable the i8042 module, but i8042 is not included when I run "lsmod"; however, there is a directory for it in /sys/module/i8042/. Not sure how or if I can disable it, but then again, I'm not at all sure that it is this module that causes my slowness problems.

A more relevant note is that I have tried hibernate also (once), and when resuming from hibernate, the system is still OK. It seems to be only when resuming from suspend that the problem pops up. Also, just closing the laptops lid and blanking the screen (no suspend or hibernate) does not cause a problem.

I will post again when I have gathered more data.

[dabl]

Good job of troubleshooting!

I'm still suspicious that something is being lost from the tmpfs filesystems during suspend. Note that in a hibernate, they get written to disk, but in suspend, the entire running system gets written to memory. That might explain why hibernate works but suspend does not.