Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a PC with two internal SATA 7,200 RPM harddisks: one is a 1 TB Western Digital, and the other is 750 GB. I'm copying data between them, but it seems to be very slow: for example, to copy 140 GB takes about 5 hours.

Does this seem reasonable?

share|improve this question

In your comment on sblair's answer you stated that:

however I believe that it is being zipped on the fly, then unzipped on the other disk.

This is the most likely cause as to your low speed.

share|improve this answer

Copying a single large file between two WD Caviar drives amounts to 85 MB/s for me. Both drives are connected to the SATA ports provided by an NVidia nForce chipset motherboard.

If the source drive is badly fragmented (typical if it is nearly full and has been used for a long time), this can slow down reading speed.

If the data you're copying consists of a large number of small files, this can drastically reduce performance. The slowest part normally is the creation of files on the target disk because each time a file is created, the OS circumvents caching to ensure the updated file system tables are written to disk.

For backup purposes, it helps to zip or rar with no compression from one hard drive to the other. Making a backup of 10 GB of small files (to an SSD with 0.1 ms seek time even) takes me 1 hour 30 minutes of copying. Using RAR with 'store' compression, the same backup takes 2 minutes.

share|improve this answer

Perhaps a badly fragmented disk, a failing disk, encrypted disk (or folders), or compressed folders?

share|improve this answer
the disks are both new, are ext3, so fragmentation shouldn;t be an issue – Daniel Oct 18 '09 at 16:16
As other have suggested, on-the-fly compression/decompression would make a difference in how long a copy operation takes. Can you turn that off? – Mike Chess Oct 18 '09 at 17:13
Had same problem as OP, ran SMART tools based on this suggestion, and behold: My tools reported aprox. 48 hours before disk failure! – daramarak Nov 29 '11 at 14:42

That's an average of about 8MB/s, which is much slower than I'd expect. Was it mostly lots of small files? Are they both SATA 3.0GB/s drives? Was another program running, such as a virus scanner? Did you copy the files in one go (one single copy and paste command), or did you have several copy operations running at the same time? These are some of the obvious questions anyway...

share|improve this answer
hi - it's around 700 files of ~200MB each. the 730GB disk is 3.0GB/s, not sure about the 1TB. I think maybe 1.0GB/s. No virus scanner or other significant disk activity: this box is running ubuntu. It's a single copy command: however I believe that it is being zipped on the fly, then unzipped on the other disk. – Daniel Oct 18 '09 at 16:11
If it is zipped on the fly and then unzipped again, this is why. That adds significant overhead. – MDMarra Oct 18 '09 at 16:15

Is this connected to the motherboard's controller (and do you know what kind it is?). From reasonable SATA disks you should be getting 60MB/s at a minimum for reading/writing. This means each disk should be using ~500mbit/s of bandwidth, and SATA goes up to 3GBit/s, so you're not even close to maxing out the bandwidth.

There are three things that could be slowing this down. One is the OS/copy method (I assume you're using Windows copy, try with a program like Total Commander, and see if it's faster). It could be a controller issue, as said above (on a nice fast Adaptec card, you can do much better than on a poor motherboard one). As said, it could be a fragmentation issue. It could also be a sign of a failing drive. Run HDTune in benchmark mode on the disks, and see what read/write you can get on each, and post the results. You should also run a scan for bad blocks, as that can highlight issues.

share|improve this answer
Re the MB controller - I have no idea. both disks are connected to the MB via yellow SATA cables. It's a linux / etx3 copy. However I've just found out the data is being zipped before being unzipped on the other disk... – Daniel Oct 18 '09 at 16:20
In that case, try watching your CPU usage (htop is nice) while doing the transfer, and see if it's maxing out. – Dentrasi Oct 18 '09 at 18:11

You must log in to answer this question.