Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

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

share|improve this question
2  
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. –  gertvdijk Feb 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 Tw Feb 8 '13 at 23:51

2 Answers 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
share|improve this answer
    
1. Yes it's ext4; 2&3. mount returns /dev/sda5 on / type ext4 (rw,noatime,discard,errors=remount-ro) so it has discard and noatime; 4. Does this data show that it's aligned or not? –  Dxr Tw Feb 9 '13 at 15:05
    
@DxrTw yes, it's aligned, because (205309952*512) mod 4096 = 0 –  Vanni Totaro Mar 21 '13 at 19:28

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.

share|improve this answer
    
Thank you for your reply. sudo hdparm -t /dev/sda returns 217.28 MB/sec; sudo hdparm -T /dev/sda returns 2850.70 MB/sec; dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync && rm -f test returns (1.1 GB) copied, 4.07706 s, 263 MB/s; dd if=/dev/zero of=/home/username/Downloads/test/test.txt bs=1M count=4096 (4.3 GB) copied, 16.0871 s, 267 MB/s. Does this data prove that actually the SSD performs well? Still, for example when I copy 1.7GB video file, the speed indicated in the copying window is 30-40mb/s while on Win7 it's 130mb/s. –  Dxr Tw Feb 9 '13 at 14:17
    
Btw, mount /dev/sda5 on / type ext4 (rw,noatime,discard,errors=remount-ro) –  Dxr Tw Feb 9 '13 at 14:17
    
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 Tw Feb 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 ;) –  Salt Feb 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? –  Salt Feb 9 '13 at 20:05

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.