I’ve been having some serious issues with disk performance. When I try to copy files the in my /home dir my transfer speeds top out at 5MB/s if I’m lucky. Yet when I benchark my disks they give me performance readings of 70-80MB/s read-wise.
Here is a screen-grab to illustrate my problem:
http://ffcreations.info/ftr.jpg
2.9MB/s? Slow!
Another issue is when I encounter any disk activity like copying any file or files over 20MB-30MB my system will slow down to a crawl or even stall until the transfer is done. Copying a file that is 500MB+ will pretty much freeze up my machine for 15-20 minutes until the transfer is done. Using iotop I noticed my IO wait times are at 99% when doing file ops of any kind. I switched my scheduler from CFQ to Anticipatory and that helped a tiny bit. Now when I transfer files I can actually launch other apps. I can multitask that is, however my copy speeds are still terrible.
Is this the infamous IO wait bug talked about here: Slashdot | Hope For Fixing Longstanding Linux I/O Wait Bug
hi,
please state:
your kernel version thru
uname -r
the mounted devices
mount -l
and of course your OpenSUSE and Gnome/KDE version.
openSUSE 11.1 64bit running with KDE 3.5
uname -r
2.6.27.21-0.1-default
mount -l
/dev/mapper/jmicron_array_part7 on / type ext3 (rw,acl,user_xattr) ]
/proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
udev on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/mapper/jmicron_array_part5 on /boot type ext3 (rw,acl,user_xattr) ]
/dev/mapper/jmicron_array_part8 on /home type ext3 (rw,acl,user_xattr) ]
/dev/mapper/isw_dghcjjbahi_bigD_part1 on /windows/D type fuseblk (rw,noexec,nosuid,nodev,allow_other,default_permissions,blksize=4096) [bigD]
fusectl on /sys/fs/fuse/connections type fusectl (rw)
securityfs on /sys/kernel/security type securityfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
There is also unmounted/wiped SATA RAID0 array that is not listed. Basically two 160GB drives in RAID0. I cloned my Linux install there thinking it was a problem with jmicron controller and the fact that I was using PATA disks. However, once the cloning was done and my install was on the much faster SATA array controlled by the ICH10R controller… well the disk perf issues were still there. So it has to be Linux related and not hardware related. I mean, two different disk controllers with different drive types (PATA vs SATA) and I still had same perf issues? Has to be Linux related.
Any assistance would be appreciated. These disk perf issues are driving me nuts.
…
that’s really weird as I have not experienced any such performance problems on 11.1 (same kernel) and Ext3. What kind of files do you copy?
(one thing to look out for is if you download torrents, you should use a client that supports pre-allocation of data. I’ve done some tests with and without pre-allocation enabled and on Ext3 at least, when copying a file that was not pre-allocated, the copy process was much slower)
When moving a file from another physical disk or RAID0 array I get better speeds, however I encounter the problem with system freeze. That is, the system will pretty much lock up until the transfer is done. Using a different scheduler helped a tiny but, but not much. When doing any sort of file operations in my local install (where my linux install is, /home, etc) I get even worse performance. Like 2.9MB/s in that screen-grab. It could be any files, located anywhere on the local and it could be any file op. Moving folders with files in them or copying a single file. It does not matter.
To clarify my above post. What I mean to say, when I do any local file ops like copying a file in on my desktop TO my desktop. However, if I’m copying a file from a different physical location to desktop I get better speeds (not much) but the system locks up.
is it possible for you to try out a different file system (say, XFS or ResierFS) and check if the problem is the same? If it is, I’m more inclined to believe it’s either a driver problem or a hardware one
Tweaking journaling and noatime/nodiratime fstab options will help somewhat (at the expense of some reliability in case of journaling), but I’d bet on what microchip8 wrote above. Did you check your BIOS settings (if any) related to RAID?
noatime does not really affect data integrity, it only affects timestamps thus slowing performance if atime is enabled. In some cases, like with mutt, it is required to enable timestamps since it relies on it. In the upcoming kernel, there will be a new option called “relative atime” (relatime) which can workaround such problems
I just created a XFS partition on my very fast RAID0 array (SATA based). I started transferring some files to it and then I copied those same files back onto that XFS partition.(local copy) Results: 3MB/s average. Highest I ever saw it was around 5-6MB/s. In other words, the perf issues are still there and I am getting only 5% to 7% of my possible throughput. Here is a screengrab from iotop to illustrate:
http://ffcreations.info/problem.jpg
What next?
…