Ubuntu: SSD on Ubuntu 12.10 Much Slower than on Win7



Question:

I have OCZ Solid 3 120GB SSD with 500MB/s Read & 450MB/s Write speeds on my Dell Inspiron R15. My primary OS is Ubuntu 12.10 (fresh) 32-bit. It runs fairly well, no freezes and overall performance is much better than on a HDD, however, just now I noticed that copying speed is much slower than on Win7. Copying a 3GB file on Win7 has around 130mb/s speed while on ubuntu it's roughly 30-40mb/s. I'm wondering why this is the case.

I followed few guides which has to optimize an SSD on linux like adding "discard,noatime" to fstab, however, this hasn't improved copying speed. It's still under 40mb/s.

Any ideas how to solve this issue?

ADHCI Enabled Dual boot (Ubuntu 12.10 & Win7) on the same OCZ Solid 3 SSD (two partitions: A for Ubuntu; and B for Win7. No Swap) Dell Inspiron 15R I3-380M 6GB RAM Radeon 6560 1GB


Solution:1

I'm surprised the difference is that great. I don't know the answer, and I have never compared I/O on a dual-boot system, but I have a few ideas.

I don't recognise the errors you got from your benchmarking program, but they can't be good. Another test for you: are there any anomalies in your disk self-monitoring data? (For example, execute gnome-disks and look for SMART data. Does it judge an OK assessment for all the attributes?)

gnome-disks also can run isolated read and write tests. I have never run a write benchmark on my SSD and I never will, but the read benchmarks are always satisfying. Are you getting advertised isolated I/O speed? Also it might be interesting to break out separate read and write speeds during your file copy, and compare to those isolated speeds from the gnome-disk benchmark. iostat -m during the copy will give you those numbers. (iostat is in the sysstat package on Debian/Ubuntu.) That's probably not terribly practical advice, but something shocking could possibly rear up.

Is your Linux file system itself in good shape? fsck is the program for finding out, but it's difficult to run on a working file system. It's easiest I think to sudo touch /forcefsck and reboot.

Say, you're not using Ext3, are you? This might be, if you upgraded to Ubuntu 12.10 over an older distro. Ext3 does not handle gigabyte-size files as efficiently as Ext4. Perhaps that's a factor. mount (just mount, no parameters) will identify the file system in play.

You may be seeing an effect of the programs you're using to do the file copy. The cp command for example, I think it isn't terribly fast or efficient. (I gather however you're using some GUI, not cp. That adds more variables though. You never know what a program is really thinking behind its GUI.)

I can't imagine noatime would have any measurable effect on copy speed of a single file. (Even so, I use it on my SSD.) discard won't help, and may slow copying. discard you know, encourages the file system to take care of the flash memory erase pass as early as possible. I'm not certain that it even works in Ubuntu 12.10 / kernel 3.5. In any case for best benchmark results, you are better served by TRIMming an SSD before the test, and this may make a large difference in write speed indeed. sudo fstrim /home for example.

The web is full of advice for other performance adjustments. It's common SSD advice to adjust your disk I/O scheduler and file system journaling enthusiasm. Here's a thread extolling the virtues of data=writeback journaling. In my opinion that advice is slightly off the mark, but it might make a difference. Some journaling configurations would be genuinely slower, but you wouldn't be using data=journal by accident.

What am I saying anyway? System performance can be home to a thousand variables. In my opinion on a few popular choices, regarding speed of copying one file: noatime, I don't see it. data=writeback possibly. discard surely not. fstrim quite possibly. fsck maybe. Outside the worrisome benchmark I/O errors you mentioned, I would guess Ext3 or an unTRIMmed disk may account for some part of the discrepancy you're seeing.


Solution:2

  1. do you use ext4 file system (file system which supports TRIM)
  2. also check if you have discard in mount options in your /etc/fstab (TRIM enabled)
  3. noatime option also helps
  4. is Ubuntu partition properly aligned (starting block number should be divisible by 4096). If is not - you get speed penalty and have to re-align it with gparted started from live linux distro

Note:If u also have question or solution just comment us below or mail us on toontricks1994@gmail.com
Previous
Next Post »