0

I am currently restoring a usb stick with a dd image, I have previously created. However is noticed very poor write speed around ~7 MB/s although the stick is usually much faster.

After looking around a little, I noticed that a lot of data is being read from the USB drive which explains the poor write performance. Nothing but dd is accessing the device at that time.

Edited atop line:

sdd: busy 101% | read 18020 | write 613 | MBr/s 7.04 | MBw/s 7.1

I noticed a similar behavior when writing directly to my md array using dd. However when writing to a mounted filesystem with dd, this does not happen.

So my question is why is read from the usb stick when writing directly to the block device and whether this can be prevented to improve write performance?

Improve this question
4
  • What specific dd command switches are you running? And what variety of file systems are you running/writing?
    – ice13berg
    Jun 1, 2015 at 10:46
  • @ice13berg I used dd if=/dev/sdX > lbzip2 image-dd.bz2 to create the image and am now using lbzcat image-dd.bz2 | dd of=/deb/sdX to restore it.
    – Antagonym
    Jun 1, 2015 at 10:48
  • Regarding the md array: RAID 5 or RAID 6? If so, are you using the stripe size as dd blocksize?
    – Hennes
    Jun 1, 2015 at 10:50
  • @Hennes It's a RAID-6 and in the case of RAID i do expect some read activity when writing due to parity calculation but less than I have seen. I did not set any blocksize for the dd command on the RAID array.
    – Antagonym
    Jun 1, 2015 at 10:54

2 Answers 2

Reset to default
1

So, not 100% clear what might be happening, but my suspicion is that you're writing small blocks (512-byte) to the USB, and then dd checks to make sure the byte is written properly - leading to LOTS of reading and writing, and reading and writing.

Tuning your block size to the "right" size isn't trivial, but there are a handfuls of rules of thumb on how to do it. In general, I've found a 64kB block size to be a good compromise on most fronts - but your file systems can drive changes to that, if you're running anything exotic (like zfs, for example).

Try something like this: lbzcat image-dd.bz2 | dd of=/deb/sdX bs=64k

For a more lengthy discussion, check out this post.

Improve this answer
2
  • Am I then correct in the assumption that, when dd'ing to a file on a filesystm, the blocksize set with dd does not matter, because the fs handles the "real" writes to the block device and has (hopefully) been setup with correct block sizes?
    – Antagonym
    Jun 1, 2015 at 10:59
  • You're definitely getting outside my lane with that question, but I think the answer is "no." I believe you'll find that if you know the file system you're writing TO, and you know the file system you're writing FROM, there is some optimal block size (or sizes) to use in dd to maximize both reading and writing complete blocks of data - optimizing the data check dd does, and minimizing the amount of incomplete written blocks. For example, I don't think using the fs would be able to help bs=3bytes or bs=61bytes.
    – ice13berg
    Jun 1, 2015 at 11:07
2

For me, dd uses the page cache by default. I think this is normal on systems with page cache. Page cache needs the storage device to be read though, which can cause slow write speed.

For me there are 3 ways of getting around this and getting full speed:

  1. Set dd block size to 4096 or a multiple. (no reads)
  2. Set dd block size to a sufficiently large number. For me this was about 1 million and above. I got full speed at about 1 million. (very few reads)
  3. Don't use page cache by giving dd parameter oflags=direct. Set dd block size to a sufficiently large multiple of 512. For me this was about bs=120k and above. (no reads)

Something to note, on my system block size for all storage devices and page size are 4096 bytes. Found with:

blockdev --getbsz /dev/sd?
getconf PAGESIZE

Also sector size is 512 bytes. fdisk and maybe parted can tell you sector size.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .