You are not logged in.

#1 2012-11-10 14:11:51

yourealwaysbe
Member
Registered: 2010-05-29
Posts: 22

Slow hard disk access --- still wonky

Hi,

Recently i've noticed that hard disk access has become very laggy, to the point
where it's driving me crazy.

For example, if i want to tab-complete through my directories, i have to wait a
few seconds each time.  Similarly with saving files in vim, or just using
firefox, which seems to suffer frequent hangs while the disk is spinning.

I tried downgrading the kernel to 3.4.something, to no avail (it definitely used
to work just fine with the old kernels).  I've also tried adding "commit=60" to
my fstab to reduce journalling access.

I ran bonnie++ and the following results came back:

Version 1.03e       ------Sequential Output------      --Sequential Input-    --Random-
                    -Per Chr-   --Block--  -Rewrite-   -Per Chr- --Block--    --Seeks--
Machine        Size K/sec   %CP K/sec  %CP K/sec %CP   K/sec %CP K/sec  %CP    /sec  %CP
mattdell      7672M 102163  88  106118 6   38973   3   83155  67 124734  4     207.5  0

                     ------Sequential Create------    --------Random Create--------
                     -Create--  --Read---  -Delete--  -Create--  --Read---  -Delete--
              files  /sec  %CP /sec  %CP  /sec  %CP   /sec  %CP  /sec  %CP  /sec  %CP
                 16  +++++ +++ +++++ +++  +++++ +++   +++++ +++  +++++ +++  +++++ +++

mattdell,7672M,102163,88,106118,6,38973,3,83155,67,124734,4,207.5,0,16,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++
t

which (by comparison with other results i've seen online) seem to indicate
there's nothing particularly wrong with the disk (it's a toshiba 7200rpm, i
think).

So i'm at a bit of a loss what to do next.  I've attached my dmesg output.  If
anyone has any suggestions, that would be awesome.

Dmesg output: http://pastebin.com/kJcbZVBT

Thanks,

Matt

Last edited by yourealwaysbe (2012-11-11 14:41:24)

Offline

#2 2012-11-10 15:41:20

Morn
Member
Registered: 2012-09-02
Posts: 345

Re: Slow hard disk access --- still wonky

Could you paste you /etc/fstab too? According to dmesg, you seem to have a remote filesystem mounted. Sometimes slow remote filesystem access or timeouts can cause other parts of the filesystem to apparently hang too, especially file save requesters in applications. At least I used to notice that with NFS filesystems…

Offline

#3 2012-11-10 17:46:17

yourealwaysbe
Member
Registered: 2010-05-29
Posts: 22

Re: Slow hard disk access --- still wonky

Remote file systems?  Weird.  There shouldn't be one, but systemd seems to be up to something in that regard.  I'll chase that up...

In the meantime, here's my fstab, nothing fancy:

# 
# /etc/fstab: static file system information
#
# <file system>	<dir>	<type>	<options>	<dump>	<pass>
tmpfs		/tmp	tmpfs	nodev,nosuid	0	0
UUID=5730f662-8c96-496d-b8e9-3a2f615709fd /boot ext2 defaults 0 1
UUID=735f91db-840c-42d3-afc3-ed7ef2fc51c7 / ext4 defaults 0 1
UUID=b581c3cf-b00d-4063-bcf6-21cbef1cfcbb /home ext4 defaults 0 1
UUID=c5f5a72a-cf6d-4b7b-9634-be922f375e38 swap swap defaults 0 0

Offline

#4 2012-11-10 18:13:48

yourealwaysbe
Member
Registered: 2010-05-29
Posts: 22

Re: Slow hard disk access --- still wonky

Morn: i disabled remote-fs using

sudo systemctl disable remote-fs.service

and rebooted, and there's a significant improvement when it comes to tabbing through directories.  Firefox still seemed to be behaving a little weirdly, so i won't flag things as resolved just yet.  Still, thanks! and well-spotted smile

The next question of course is, what the hell was systemd up to...?

Last edited by yourealwaysbe (2012-11-10 18:23:08)

Offline

#5 2012-11-10 18:34:55

Morn
Member
Registered: 2012-09-02
Posts: 345

Re: Slow hard disk access --- still wonky

Systemd is a little too smart for its own good; maybe it auto-detected something and thought it needed to start network filesystems. Very weird behavior indeed… But systemd is still more bleeding edge than leading edge at the moment, so I can't say I'm all that surprised. smile

If you are still experiencing issues with Firefox, maybe those are also systemd-related somehow? Perhaps you should try Chromium and see if you notice the same problems. That should narrow it down.

P.S. Thanks for mentioning ionice BTW, I didn't know that command.

Last edited by Morn (2012-11-10 18:49:32)

Offline

#6 2012-11-11 14:43:59

yourealwaysbe
Member
Registered: 2010-05-29
Posts: 22

Re: Slow hard disk access --- still wonky

Arf -- i noticed firefox was still laggy last night, and on a (second or third) reboot this morning, things are back to being laggy even without having run firefox...

I'm not sure where to look, but here's the output of mount if that will be of any use:

proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
dev on /dev type devtmpfs (rw,nosuid,relatime,size=1962404k,nr_inodes=490601,mode=755)
run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
/dev/sda3 on / type ext4 (rw,relatime,data=ordered)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=27,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime)
/dev/sda1 on /boot type ext2 (rw,relatime)
/dev/sda4 on /home type ext4 (rw,relatime,data=ordered)

All suggestions appreciated smile


edit: also, nothing untoward reported by top (i don't think):

top - 15:52:02 up 16 min,  0 users,  load average: 0.36, 0.41, 0.30
Tasks: 104 total,   2 running, 102 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.1 us,  0.2 sy,  0.0 ni, 99.8 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:   3930516 total,   779240 used,  3151276 free,    51616 buffers
KiB Swap:  2626620 total,        0 used,  2626620 free,   285284 cached

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM     TIME+ COMMAND
    1 root      20   0 32552 3432 1924 S   0.0  0.1   0:00.51 systemd
    2 root      20   0     0    0    0 S   0.0  0.0   0:00.00 kthreadd
    3 root      20   0     0    0    0 S   0.0  0.0   0:00.04 ksoftirqd/0
    4 root      20   0     0    0    0 S   0.0  0.0   0:00.14 kworker/0:0
    5 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 kworker/0:0H
    7 root       0 -20     0    0    0 S   0.0  0.0   0:00.00 kworker/u:0H
    8 root      rt   0     0    0    0 S   0.0  0.0   0:00.00 migration/0
    9 root      rt   0     0    0    0 S   0.0  0.0   0:00.00 watchdog/0
   10 root      rt   0     0    0    0 S   0.0  0.0   0:00.00 migration/1

The lag tends to occur when first tabbing into a directory.  On the second time
tabbing through things seem to be fast -- i guess that's cached somewhere.

editedit: i also tried switching back to initscripts, with no improvement, so i guess systemd is off the hook for the remaining problems smile

Last edited by yourealwaysbe (2012-11-11 15:13:57)

Offline

#7 2012-11-11 17:21:31

Morn
Member
Registered: 2012-09-02
Posts: 345

Re: Slow hard disk access --- still wonky

Have you tried an older kernel, e.g. 3.5.6? I don't trust the 3.6 series at all…

You should also make sure "Don't load tabs until selected" is deselected in the Firefox prefs. It's a stupid default in newer Firefox versions that makes initial tab switching sluggish.

Offline

#8 2012-11-11 17:26:33

yourealwaysbe
Member
Registered: 2010-05-29
Posts: 22

Re: Slow hard disk access --- still wonky

Thanks for the suggestions.  I tried downgrading to 3.4.something with no improvement.  Also, with firefox, the pauses come even while typing into the text boxes (three times during this paragraph...).

It does feel like a general context switching problem though.  It's most noticable after having just changed window (as if it's paging a whole load of stuff), but it still persists less often after having been in the same window for a while.

Offline

#9 2012-11-11 17:40:23

Morn
Member
Registered: 2012-09-02
Posts: 345

Re: Slow hard disk access --- still wonky

If you turn off X and log into the text console, do you get the same pauses in e.g. vim?

Offline

#10 2012-11-12 08:12:07

yourealwaysbe
Member
Registered: 2010-05-29
Posts: 22

Re: Slow hard disk access --- still wonky

Yeah -- it still happens if i boot just to a console hmm

I'll try playing with swappiness and things: https://wiki.archlinux.org/index.php/Ma … Swappiness

Offline

#11 2012-11-12 09:28:52

Morn
Member
Registered: 2012-09-02
Posts: 345

Re: Slow hard disk access --- still wonky

According to top, swap isn't used at all (and why would it would with all that RAM). Still, you could try to turn off swap just in case. I only have a measly 4 GB RAM, but so far I'm doing just fine without swap. I have conky running though so I know when I'm using too much RAM.

Maybe you should post your pstree output too. In fact we have a dedicated thread for that on here somewhere. smile

But to me this is looking more and more like a hardware issue. So another thing you want to try is booting Linux with "maxcpus=1" and see what happens. In fact there seems to be an alternative method to achieve that on a running machine via /sys/devices/system/cpu/: http://pundiramit.blogspot.com/2010/07/ … icore.html

Also, unplug the Ethernet cable / turn off WiFi. Network adapters can block or lock up the whole machine sometimes, at least with older kernel versions. Try to unplug all non-essential USB devices. If you have both on-board graphics and a dedicated graphics card, give on-board graphics a try. (It will suck for 3-D performance of course.) Are you using any other unusual hardware that might be responsible?

Last edited by Morn (2012-11-12 09:31:24)

Offline

#12 2012-11-12 09:54:50

yourealwaysbe
Member
Registered: 2010-05-29
Posts: 22

Re: Slow hard disk access --- still wonky

Thanks again for all your help smile

Here's my current pstree:

systemd
  ├─acpid -f
  ├─agetty --noclear tty1 38400
  ├─at-spi-bus-laun
  │   ├─dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3
  │   └─3*[{at-spi-bus-laun}]
  ├─at-spi2-registr --use-gnome-session
  │   └─{at-spi2-registr}
  ├─crond -n
  ├─dbus-daemon --fork --print-pid 5 --print-address 7 --session
  ├─dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
  ├─dbus-daemon --fork --print-pid 5 --print-address 7 --session
  ├─dbus-launch --autolaunch 71d631bd5ed458f15961c91800000209 --binary-syntax --close-stderr
  ├─dbus-launch --autolaunch 71d631bd5ed458f15961c91800000209 --binary-syntax --close-stderr
  ├─dhclient -q -e TIMEOUT=10 -pf /run/dhclient-wlan0.pid wlan0
  ├─gvim
  ├─minbif /etc/minbif/minbif.conf
  │   └─minbif /etc/minbif/minbif.conf
  ├─mutt_bgrun /home/matt/bin/mutt_bgrun firefox /tmp/mutt.html
  │   └─firefox /dev/shm/matt600/mutt.html
  │       ├─plugin-containe /usr/lib/mozilla/plugins/libflashplayer.so -greomni /usr/lib/firefox/omni.ja 604 plugin
  │       │   └─6*[{plugin-containe}]
  │       └─26*[{firefox}]
  ├─slim -nodaemon
  │   ├─X -nolisten tcp vt07 -auth /var/run/slim.auth
  │   └─bash -login /home/matt/.xinitrc xfce4
  │       ├─dunst
  │       └─xmonad-x86_64-l
  │           ├─urxvt -T Mutt -name Mutt -e /home/matt/bin/start-mutt
  │           │   └─sh /home/matt/bin/start-mutt
  │           │       └─mutt
  │           ├─urxvt -T Irssi -name Irssi -e /home/matt/bin/start_irssi
  │           │   └─start_irssi /home/matt/bin/start_irssi
  │           │       └─irssi
  │           │           └─{irssi}
  │           ├─urxvt
  │           │   └─zsh
  │           │       └─pstree -a
  │           └─xmobar -B #e7e7e7 -F black -f ...
  ├─systemd-journal
  ├─systemd-logind
  ├─systemd-udevd
  └─wpa_supplicant -B -P /run/wpa_supplicant_wlan0.pid -i wlan0 -D nl80211,wext -c/run/network/wpa.wlan0/wpa.conf

I'll give all your suggestions a try -- it may take me a couple of days though (i'm travelling today and stuck at some work event tomorrow, and it can be a bit intermittent about whether it accesses the disk ok or not...).

Offline

#13 2012-11-12 10:10:46

Morn
Member
Registered: 2012-09-02
Posts: 345

Re: Slow hard disk access --- still wonky

yourealwaysbe wrote:

Thanks again for all your help smile

Here's my current pstree:

systemd
  ├─acpid -f
  ├─agetty --noclear tty1 38400
  ├─at-spi-bus-laun
  │   ├─dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3
  │   └─3*[{at-spi-bus-laun}]
  ├─at-spi2-registr --use-gnome-session
  │   └─{at-spi2-registr}
  ├─crond -n
  ├─dbus-daemon --fork --print-pid 5 --print-address 7 --session
  ├─dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
  ├─dbus-daemon --fork --print-pid 5 --print-address 7 --session
  ├─dbus-launch --autolaunch 71d631bd5ed458f15961c91800000209 --binary-syntax --close-stderr
  ├─dbus-launch --autolaunch 71d631bd5ed458f15961c91800000209 --binary-syntax --close-stderr
  ├─dhclient -q -e TIMEOUT=10 -pf /run/dhclient-wlan0.pid wlan0
  ├─gvim
  ├─minbif /etc/minbif/minbif.conf
  │   └─minbif /etc/minbif/minbif.conf
  ├─mutt_bgrun /home/matt/bin/mutt_bgrun firefox /tmp/mutt.html
  │   └─firefox /dev/shm/matt600/mutt.html
  │       ├─plugin-containe /usr/lib/mozilla/plugins/libflashplayer.so -greomni /usr/lib/firefox/omni.ja 604 plugin
  │       │   └─6*[{plugin-containe}]
  │       └─26*[{firefox}]
  ├─slim -nodaemon
  │   ├─X -nolisten tcp vt07 -auth /var/run/slim.auth
  │   └─bash -login /home/matt/.xinitrc xfce4
  │       ├─dunst
  │       └─xmonad-x86_64-l
  │           ├─urxvt -T Mutt -name Mutt -e /home/matt/bin/start-mutt
  │           │   └─sh /home/matt/bin/start-mutt
  │           │       └─mutt
  │           ├─urxvt -T Irssi -name Irssi -e /home/matt/bin/start_irssi
  │           │   └─start_irssi /home/matt/bin/start_irssi
  │           │       └─irssi
  │           │           └─{irssi}
  │           ├─urxvt
  │           │   └─zsh
  │           │       └─pstree -a
  │           └─xmobar -B #e7e7e7 -F black -f ...
  ├─systemd-journal
  ├─systemd-logind
  ├─systemd-udevd
  └─wpa_supplicant -B -P /run/wpa_supplicant_wlan0.pid -i wlan0 -D nl80211,wext -c/run/network/wpa.wlan0/wpa.conf

I'll give all your suggestions a try -- it may take me a couple of days though (i'm travelling today and stuck at some work event tomorrow, and it can be a bit intermittent about whether it accesses the disk ok or not...).

If you have little time, I'd start by disabling WiFi and unloading the WiFi kernel driver. As for running with fewer cores, I think the reboot method is safer after all, according to that blog I linked to.

Pstree doesn't look unusual to me, except you have two dbus-launch instances running. I don't know if that's normal; I only have one. You might try turning off the dbus daemon for a while before you start messing with boot parameters. smile

Offline

#14 2012-11-12 12:48:15

yourealwaysbe
Member
Registered: 2010-05-29
Posts: 22

Re: Slow hard disk access --- still wonky

Morn wrote:

Pstree doesn't look unusual to me, except you have two dbus-launch instances running. I don't know if that's normal; I only have one. You might try turning off the dbus daemon for a while before you start messing with boot parameters. smile

Looks like it's not normal: i was starting minbif all wrong... though it's not the cause of the lags.

Healthier pstree smile:

systemd
  ├─acpid -f
  ├─agetty --noclear tty1 38400
  ├─crond -n
  ├─dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
  ├─dbus-daemon --fork --print-pid 5 --print-address 7 --session
  ├─dbus-launch --autolaunch 71d631bd5ed458f15961c91800000209 --binary-syntax --close-stderr
  ├─dhclient -q -e TIMEOUT=10 -pf /run/dhclient-wlan0.pid wlan0
  ├─dhcpcd -A -q -w eth0
  ├─minbif --pidfile /run/minbif/minbif.pid /etc/minbif/minbif.conf
  │   └─minbif --pidfile /run/minbif/minbif.pid /etc/minbif/minbif.conf
  │       └─minbif --pidfile /run/minbif/minbif.pid /etc/minbif/minbif.conf
  ├─slim -nodaemon
  │   ├─X -nolisten tcp vt07 -auth /var/run/slim.auth
  │   └─bash -login /home/matt/.xinitrc xfce4
  │       ├─dunst
  │       └─xmonad-x86_64-l
  │           ├─urxvt
  │           │   └─zsh
  │           │       └─pstree -a
  │           ├─urxvt -T Mutt -name Mutt -e /home/matt/bin/start-mutt
  │           │   └─sh /home/matt/bin/start-mutt
  │           │       └─mutt
  │           ├─urxvt -T Irssi -name Irssi -e /home/matt/bin/start_irssi
  │           │   └─start_irssi /home/matt/bin/start_irssi
  │           │       └─irssi
  │           │           └─{irssi}
  │           └─xmobar -B #e7e7e7 -F black -f ...
  ├─systemd-journal
  ├─systemd-logind
  ├─systemd-readahe collect
  ├─systemd-udevd
  └─wpa_supplicant -B -P /run/wpa_supplicant_wlan0.pid -i wlan0 -D nl80211,wext -c/run/network/wpa.wlan0/wpa.conf

I'll get back to you about the other suggestions soon smile  Thanks.

edit: healthier except for having dhclient and dhcpcd running... guess i should sort that out too.  I killed the redundant dhcpcd, but it still lags.

Last edited by yourealwaysbe (2012-11-12 12:50:35)

Offline

#15 2012-11-12 13:26:17

Morn
Member
Registered: 2012-09-02
Posts: 345

Re: Slow hard disk access --- still wonky

So it looks like your Arch installation has had quite a few configuration problems thus far. Maybe it's a good thing they get fixed, even if they do not cause the lags.

If you don't have other operating systems on the machine for testing, you might want to download a Linux Live CD such as Knoppix and boot that from a CD or USB thumb drive. If Knoppix also lags, it has to be a hardware problem IMO. If it doesn't, at least you now have a working OS to browse the web with. smile

Offline

#16 2012-11-12 22:27:38

yourealwaysbe
Member
Registered: 2010-05-29
Posts: 22

Re: Slow hard disk access --- still wonky

There's the same lag with wifi/ethernet disabled (modules unloaded) and with maxcpus=1. 

The drive also lags when running from an arch installation i have on a usb key that i set up a few months ago, so i guess it is something going on with the drive hmm

Or maybe it's just normal behaviour that i never noticed before -- if i have the machine running for a while, things seem to improve, but after first boot they're messy (or after any system stress really -- there's a context-switchy feel to it, so maybe that's why bonnie++ returned decent results).

I'll keep an eye on this to see if i get anywhere (though i'm still open to suggestions) -- the system's certainly usable.  Fingers crossed it doesn't die in the coming weeks...

Thanks for all the advice smile

Offline

#17 2012-11-13 11:06:57

Morn
Member
Registered: 2012-09-02
Posts: 345

Re: Slow hard disk access --- still wonky

So if you boot from your USB key but don't mount the hard drive, you don't get lags?

Offline

#18 2012-11-13 17:43:23

yourealwaysbe
Member
Registered: 2010-05-29
Posts: 22

Re: Slow hard disk access --- still wonky

Morn wrote:

So if you boot from your USB key but don't mount the hard drive, you don't get lags?

If i mount from usb and then mount the harddrive, then

1) navigating the harddrive is laggy (first ls of each directory takes 2s or so)
2) navigating the usb key is super smooth

and vice versa: if i boot from the harddrive, then mount a usb key, then it's the same (1) and (2) as above.

Offline

#19 2012-11-13 19:50:28

Morn
Member
Registered: 2012-09-02
Posts: 345

Re: Slow hard disk access --- still wonky

Wow, then the problem is really odd. A hard drive that isn't doing anything shouldn't cause the system to lag, should it. And you can get the USB key to lag too, if you do it the other way around? Weird.

Going back to your dmesg, what's this:

[    7.410250] sdhci: Secure Digital Host Controller Interface driver
[    7.410253] sdhci: Copyright(c) Pierre Ossman
[    7.410807] sdhci-pci 0000:0a:00.0: SDHCI controller found [1217:8221] (rev 5)
[    7.412601] sdhci-pci 0000:0a:00.0: Invalid iomem size. You may experience problems.

Unfortunately I have no idea what a Secure Digital Host Controller is or does, but it looks like a possible problem.

Offline

#20 2012-11-13 20:44:47

yourealwaysbe
Member
Registered: 2010-05-29
Posts: 22

Re: Slow hard disk access --- still wonky

Morn wrote:

Wow, then the problem is really odd. A hard drive that isn't doing anything shouldn't cause the system to lag, should it. And you can get the USB key to lag too, if you do it the other way around? Weird.

Ah, no, maybe i wasn't clear: the usb key never lags, the lag is *only* when accessing the harddisk.  So, even if the harddisk is mounted, the usb access is lag-free. 

But, regardless of whether i'm running my usb install or the install on my harddisk, doing things like "ls" on directories stored on the harddisk causes a delay.  (While doing "ls" on directories stored on the usb key is perfectly instantaneous.)

Going back to your dmesg, what's this:

[    7.410250] sdhci: Secure Digital Host Controller Interface driver
[    7.410253] sdhci: Copyright(c) Pierre Ossman
[    7.410807] sdhci-pci 0000:0a:00.0: SDHCI controller found [1217:8221] (rev 5)
[    7.412601] sdhci-pci 0000:0a:00.0: Invalid iomem size. You may experience problems.

Unfortunately I have no idea what a Secure Digital Host Controller is or does, but it looks like a possible problem.

Ah, yeah -- i googled this a while ago since it's been there from the very beginning.  I think it was some issue with the harddisk vs. the kernel that was known to be benign (i think the source i found was a bug report saying they should get rid of the warning in this case.  I'll dig around to see if i can find it again).

edit: ok, i can't find what i read, but if i unload the sdhci and sdhci_pci modules, there's still a lag on the harddisk.

Last edited by yourealwaysbe (2012-11-13 21:09:46)

Offline

#21 2012-11-14 09:04:24

Morn
Member
Registered: 2012-09-02
Posts: 345

Re: Slow hard disk access --- still wonky

As the only point where this hard does not lag seems to be in the past (i.e., you seem to have been unable right now to find a config where it does not lag), maybe you should focus more on what has changed on the system. When did you notice the problem for the first time? After an upgrade? After installing new hardware?

I've found this Windows-centric thread about HD power-saving features and lags: http://www.tomshardware.co.uk/forum/268 … ning-files

"hdparm -S" lets you set the time until HD spin-down occurs; maybe you should check its current value or even set it to zero to disable spin-down entirely.

Last edited by Morn (2012-11-14 09:04:48)

Offline

#22 2012-11-14 18:11:06

yourealwaysbe
Member
Registered: 2010-05-29
Posts: 22

Re: Slow hard disk access --- still wonky

Thanks for the link.  I tried changing the spindown types, but it doesn't help much.  I will look into other power saving features when i get a chance to power down.

In the meantime, i tried hdparm -tT to do some tests (with hdparm -S 240 (20 minutes)).  I found, after leaving the machine to idle for 5 minutes, i got these kind of results (i ran the command three times):

 Timing cached reads:   13428 MB in  2.00 seconds = 6718.97 MB/sec
 Timing buffered disk reads: 354 MB in  3.01 seconds = 117.56 MB/sec

but after another five minutes left idle (and three runs of the command)

 Timing cached reads:   8254 MB in  2.00 seconds = 4128.82 MB/sec
 Timing buffered disk reads:  22 MB in  3.00 seconds =   7.33 MB/sec

so i'm not sure why the fluctuation in buffered disk reads...  Admittedly i hadn't made sure all processes were stopped (only the obvious ones like firefox, email, instant messaging), but there was no disk activity going on before/during/after the tests.

edit: today i notice a kind of intermittent clicky hum sound coming from beneath my keyboard... i'm hoping that's not bad...

Last edited by yourealwaysbe (2012-11-14 18:14:21)

Offline

#23 2012-11-14 18:21:21

Morn
Member
Registered: 2012-09-02
Posts: 345

Re: Slow hard disk access --- still wonky

Not to be negative, but I'd definitely back up my important data right now—if you haven't already—before you get the Click of Death. sad

What do the S.M.A.R.T. HD diagnostics say about drive health? "pacman -S smartmontools"…

Offline

#24 2012-11-14 18:24:05

yourealwaysbe
Member
Registered: 2010-05-29
Posts: 22

Re: Slow hard disk access --- still wonky

Morn wrote:

Not to be negative, but I'd definitely back up my important data right now—if you haven't already—before you get the Click of Death. sad

Hah, yeah, thinking about that... (though all my important data is already backed up remotely.)

What do the S.M.A.R.T. HD diagnostics say about drive health? "pacman -S smartmontools"…

They've been saying everything's all fine so far.  I just started a long test, so we'll see what that says.

Offline

#25 2012-11-14 18:43:08

Morn
Member
Registered: 2012-09-02
Posts: 345

Re: Slow hard disk access --- still wonky

yourealwaysbe wrote:

They've been saying everything's all fine so far.  I just started a long test, so we'll see what that says.

I wouldn't necessarily trust the diagnostics if it says all is fine. That just means the diagnostics are useless in this case. But if it thinks the drive is about to fail it probably will.

Maybe it's the universe's way to tell you it is time for an SSD? smile

Offline

Board footer

Powered by FluxBB