anyone know why this would happen? I ran the following dd command:

a USB external drive was mounted to the 'hard' directory with the standard mount command. it is a ntfs-3g filesystem. it is a mechanical drive.

same behavior with solid state memory (flash, and solid state hard drives)


3693492+0 records in
3693492+0 records out
1891067904 bytes (1.9 GB) copied, 274.562 s, 6.9 MB/s
7083789+0 records in
7083789+0 records out
3626899968 bytes (3.6 GB) copied, 552.678 s, 6.6 MB/s
7349092+0 records in
7349092+0 records out
3762735104 bytes (3.8 GB) copied, 576.682 s, 6.5 MB/s
9762943+0 records in
9762943+0 records out
4998626816 bytes (5.0 GB) copied, 782.539 s, 6.4 MB/s
10257790+0 records in
10257790+0 records out
5251988480 bytes (5.3 GB) copied, 826.804 s, 6.4 MB/s
17000321+0 records in
17000321+0 records out
8704164352 bytes (8.7 GB) copied, 1494.76 s, 5.8 MB/s
37069401+0 records in
37069401+0 records out
18979533312 bytes (19 GB) copied, 3982.31 s, 4.8 MB/s
79391274+0 records in
79391274+0 records out
40648332288 bytes (41 GB) copied, 14068.8 s, 2.9 MB/s
144385881+0 records in
144385881+0 records out
73925571072 bytes (74 GB) copied, 47609.8 s, 1.6 MB/s
194700873+0 records in
194700873+0 records out
99686846976 bytes (100 GB) copied, 94929.3 s, 1.1 MB/s
201734145+0 records in
201734145+0 records out
103287882240 bytes (103 GB) copied, 103429 s, 999 kB/s
202499967+0 records in
202499967+0 records out
103679983104 bytes (104 GB) copied, 104408 s, 993 kB/s
204796557+0 records in
204796557+0 records out
104855837184 bytes (105 GB) copied, 107298 s, 977 kB/s

All that in response to one dd command??!!

What is the size of the partition being copied?

How much free space is on the target drive?

If the source partition is ~100GB as implied by the command output, then what kind of flash drive were you copying to? More generally, are you saying that the behavior is identical for different target drives?

Not sure what this is suppose to mean....but yes, so you can see the transfer rate decline in a fairly rapid linear fashion.

105GB
300GB

Yes, this was meant in a more general sense, I tried various types of storage devices (as source and target) and had a similar linear decline. At this point the size, and type of device is irrelevant since the behavior is the same for all.

I simply asked if dd did all that by itself....I have never seen such a thing. Anytime I ever used dd, it printed the statistics once at the end of the job.

For the moment, I can't think of what might be causing this. Have you tried different block sizes?

The destination hard drive has a cache (they all have cache, some bigger, some smaller). At the start, notable part of data has been written to cache, which is fast. As more and more data is copied, then the effect of the cache gets smaller and the write speed you are seeing is getting closer to actual write speed of the magnetic media on HD.

by default, dd uses 512 byte writes, which has really poor performance on some drives. if the amount of data to be copied is multiple of 2kb (2048 bytes), try using bs=2k parameter with dd. That will increase speed noticeably. Even better if you can use 4k (multiple of 4096) or 8k (8192)

1 members found this post helpful.

That's correct but HDD drive caches are a few tens of MB so the phenomenon you describe would only be effective for the first part of the reported transfer, and would be invisible for the data quantities reported.

AFAIK HDDs read/write faster at the outer edge of the drive because the spin speed is constant and so the linear distance travelled per second is greater when the head is further out. This could be causing (some of?) the effect but doesn't make sense when writing only ~30% of the HDD capacity, assuming writing starts at the outside and moves inward.

It may be instructive to explore what happens when using dd's seek option to start recording, say, 80 GB from the start.

Another possibility is that the limiting factor is not the output device but the input device, especially if this unusual behaviour is seen on multiple output devices. This could be tested by using /dev/null as the output device.

Was there any other activity on the input and output devices when the tests were run?

Nope, I made sure to do nothing else on either IO device...

I am aware of drive caches, but my only reason for not exploring that as a solution was because we should have seen the data transfer rate level off at some point, as catkin implied, but it continues to decline in a linear fashion??

if you send the currently running dd process the USR1 signal it will print the current statistics

1 members found this post helpful.

Because linux has a filesystem cache/buffers in system memory in addition to the much smaller write buffers on the device itself it's very likely that the first few GB or so (depending on the amount of free ram your system has) is going to get an exceptionally high transfer rate, but once those buffers are saturated the actual rate will drop to the sustained rate of the device. However, what you need to remember is that the transfer rate that dd reports is the averaged transfer rate from the start of the dd operation which will be artificially high due to the head-start it got from the buffering and will gradually trend towards the actual sustained transfer rate. This may explain what you're seeing.

If you want to be certain, then instead of watching the averaged rate reported by dd, try running something like iostat that can report the actual rate over real time intervals.


Anyway, that's my guess at what's happening. I could be wrong.

Are the filesystem cache/buffers likely to hold the data that dd reads, though? I'm no expert but I assume they only hold already-read data plus maybe some read-ahead. Even if the dd input had already been done, wouldn't the cache/buffers hold the last data read, up to their capacity? Unless the system has ~100 GB memory I'm dubious that the cache/buffers are significant.

Regards dd printing an averaged rate that's useful to know but it means the real rate slowed down even more than the figures reported.

The initial rate looks like a reasonable maximum for current storage devices.

I wonder if some device in the chain may be overheating and de-loading itself but AFAIK only CPUs do that, not HDDs or bus controllers, and the reported transfer rate shouldn't make a current model CPU break sweat unless its cooling system is defective.

@catkin,

I'm not really sure about the internals of the vfs cache/buffer, I was thinking more of the effect of write buffering rather than any effect the read cache may have had on the overall average, but looking a little closer at the raw data between 5.0GB and 74GB we get:

4998626816 bytes (5.0 GB) copied, 782.539 s, 6.4 MB/s
73925571072 bytes (74 GB) copied, 47609.8 s, 1.6 MB/s

So the average rate between the two observations:

73925571072 - 4998626816 =
68926944256 (bytes)
47609 - 782 =
46827 (seconds)
68926944256 / 46827
1471948 (bytes/sec) = 1471KB/sec


Similarly between the 41GB and 100GB points, it's:

99686846976 - 40648332288
59038514688
94929 - 14068
80861
59038514688 / 80861
730123 = 730KB/sec

So, it's certainly not a consistent rate and any buffering should have been well out of the way after that initial 5GB, so that shouldn't factor either.

Really not sure what's going on now.

I'm not sure if the cache would have anything to do with it at this point?? and here is why:

there are various cache algorithms out there. Some common ones are MRU, and LRU, (Most/Least Recently Used) google search of "cache algorithms" should get you there fine. I have implemented a MRU cache, basically, any new data that hasn't been seen before will overwrite the piece of data with the lowest frequency/visits if you will. In this case where you are making an exact copy of a hard drive there really are no addresses that are visited more than once, effectively ruling out the vary purpose of the cache. Again, I am unsure, this is my best guess....I am confused.

Perhaps the hard drive gets tired, maybe I should give it some water?

I'm still stuck on the question of how to get dd to print out multiple progress reports----did I miss it?

I have NEVER seen dd give anything except the total time at the end.

Koooee, what hardware software (distro) and type of computer and usb port type and file system types are you using?

On a 2GHz AMD64 debian lenny laptop, bought in 2004, with 2GB ram and a 100GB 5400rpm hdd and usb2, I regularly (one a week) get dd transfer rates of between 22MB/s and 17MB/s transferring (backing-up) partitions of between 11GB to 23GB to a (2008 vintage) Western Digital Passport 320GB 5400rpm usb2 powered external drive. This is approximately the same speed that I get when copying between partitions on my internal harddrive.

So I am surprised that you are getting such slow speed. However, my command using 'dd' adds a few things that you are missing: dd if=/dev/hda6 of/dev/sdb9/deb.image bs=2048 conv=notrunc,noerror

My thoughts are that without the notrunc(ate) and noerror parameters you are suffering from severe error checking or that your external hdd is suffering from bad sectors are some other ailment.

The foregoing is based on the assumption that the if= and of= file systems are formatted with the same filesystems, that you are not using an old usb port (rather than usb2) on both ends of your connection, and that your wire is no longer than 3 feet (mine is only about 12 inches long). I also assume that you are reformatting the external hdd between running the dd commands in your first post - otherwise you are trying to overwrite existing data, which while not usually a disaster, does mean that the process will be slower than writing to a clean partition.

finally, I would add that I am careful to ensure that my external hdd partition is *unmounted* before issuing the dd command. try this it may be faster, but you will have to know which partition on the external hdd you want to dd to. It is partitioned, isn't it?

1 members found this post helpful.

Writes aligned to the erase buffer size of the SSD may provide the best performance. You may be performing a read/update/erase/write cycle on your SSD device for each 512 byte write at some point. For normal writing, the file system partition alignment may need to match some the erase buffer size as well to prevent the device from writing twice.

This blog entry covers these items: http://thunk.org/tytso/blog/2009/02/...se-block-size/

To maximize throughput, you may need to make the sector size of the dd command match the size the erase buffer and also align the beginning of the partition to start on the start of the a cylinder for the ssd drive. Otherwise it will need to erase two buffer sized areas before updating them for each one buffer sized write.

Slackware 13.0 64bit
SMP_Kernal (default)
2 Intel Xeon Quad-Core's @ 2.3GHz
12GB Memory
source= 160GB SeaGate hdd SATA (fairly old so I'm guessing 5400rpm, specs aren't on the drive)
target= 400GB SeaGate external 5400rpm USB 2.0, external power

Sector size for each drive is 512 bytes, I guess I never tried to go higher than that because I was afraid of alignment issues? Perhaps I don't have a deep enough understanding of this? Could you help?
Your assumptions are correct.
the drive in which it received the 6mb/s transfer rate had one massive partition, slow speed on those two could very likely be due to bad sectors and/or old hardware. But, I am most concerned with the consistent linear decline in the transfer rate, regardless of the hardware I am using for the source and target??

@jschiwal --
Thanks for the informative article, very useful information. But, the article was only for SSD's, the effect I am interested about is a superset of SSD's which contains SS Memory, and Mechanical Memory.

@pixellany --
I have seen this command in different forms
I can't condone for the first two, as the last one is what I use. The first two don't work for me, nor are they specified in the grammar of my kill command, I would check out 'man kill' for grammar specs.