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.

Welcome to Ask Ubuntu! How are you actually measuring the speed of your SSD? Are you copying files from another medium to it or the other way around? If so, what kind of medium is that? And what is the indication that your SSD is the bottleneck here? Please run a "real" benchmark or use the benchmark tool in "Disks" to check the actual performance more reliably.
–
gertvdijkFeb 8 '13 at 22:46

Thank you for your reply. I copy from one location on the partition to another location of the same partition, so on Win7 the SSD speed is 130mb/s while on ubuntu 12.10 32-bit it's 30-40mb/s. I see the mb/s indicated while copying the files. I checked that in ubuntu it copies roughly 800mb within 20secs while in win7 it manages to copy more than 1700mb within 20secs .So there's is a dramatic loss of speed for some reason. Also, Disks Benchmark errors: 1. Error pre-reading 4096 bytes from offset 0 (g-io-error-quark, 0); 2. Error opening /dev/sda5: Device or resource busy (udisks-error-quark, 0)
–
Dxr TwFeb 8 '13 at 23:51

2 Answers
2

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.

I'm not sure if my partition is correctly aligned. How do I check it? I tried the following: sudo parted -l unit s which returned results available at link. Do you see any problems in this data?
–
Dxr TwFeb 9 '13 at 14:52

I say your hdparm and dd tests show reasonable numbers for a decent recent laptop with an SSD. hdparm -t gives me 340 MB/sec; I'm using an OCZ Vertex 3 on a desktop. Still refusing to burn up disk in a write test ;)
–
SaltFeb 9 '13 at 20:03

The OCZ Solid 120MB is spec'd at 20K read and 20K write ops/sec. If the device is limited to 20K ops/sec total, which I think is likely, then 39MB/sec is the best speed you could get, copying a file on the same device, using a 4K copy buffer with no disk buffer. Of course you're not getting unbuffered I/O, that's silly, but I wonder if the performance difference is because the Windows file copy program does a better job speaking OCZ Solid. Does file copy speed pick up, using dd between two real files with a large block size?
–
SaltFeb 9 '13 at 20:05