Optimizing DD Block Size for SSD Imaging

Overview

When imaging SSDs for my thin clients using dd, I was only getting 3.7MB/s transfer rates. After experimenting with different block sizes, I discovered that 4K blocks doubled my performance to 7.3MB/s. In this video, I test various block sizes (1K, 4K, 8K) and explain why 4K is likely the sweet spot for SSD controllers. If you use dd or gdd for disk imaging, this could save you significant time.

Key Moments

• Default block size: 3.7 MB/s transfer rate (too slow)
• Testing 4K block size: jumped to 7.2-7.3 MB/s (nearly doubled!)
• Testing 1K block size: dropped back to 3.3-3.4 MB/s
• Testing 8K block size: decreased to 6.6 MB/s
• Conclusion: 4K is the sweet spot for these IDE SSDs
• Theory: SSD controllers prefer 4KB chunks for internal operations
• Using USB to IDE adapter and gdd (shows progress)
• Warning about dd being dangerous—use Disk Utility to verify target drive
• Hardware engineer perspective on why 4K works best

Full Transcript (Edited)

Hello everybody, so today I wanted to show you a little bit of an experiment that I’m running. I have these little SSD IDE drives—well, I wouldn’t say hard drives, they’re solid-state drives—that go into some of the thin clients that I post videos about.

To set up my thin clients, I usually use dd to copy a disk image that I previously created using a USB to IDE adapter like this. As you can see, this one, this drive right here, is being written right now.

Today what I’m doing is I’m experimenting with block sizes to see if I can improve the performance of the disk image writes. As you can see here, on my previous writes to another disk, I was getting 3.7 megabytes per second to transfer a four-gigabyte image. That was without setting any block size. I think the default could be 64K, or I’ll take a look really quick, but I think it’s a large block size by default if we don’t specify it in the command line.

I’m using gdd because gdd has the ability to show the progress. Now take a look below here. I was looking online to see what the ideal block size for an SSD would be, and some controllers and some articles mentioned that some controllers like to use four kilobytes as the transfer rate.

Mind you, I have this as my controller here—whatever is inside that thing. This is supposed to be USB 3, but I’m constrained by how fast the controller on the SSD itself works. On the left here is the memory chip—this Flash—and this is the controller. So I’m constrained by the performance between this and that.

In my experiment here, I chose to go with four kilobytes, and as you can see here, it jumped up—it doubled pretty much from 3.7 megabytes to 7.2 megabytes. I’m already at 2 gigabytes transferred.

What I’m going to do is I’m going to let this run. It looks like it’s going to end up being 7.2 megabytes to write this. Then I’m gonna try doing a write with one kilobyte block size to see if that increases or if it decreases. Then I’m gonna do eight kilobytes and see in what direction it goes. Maybe four kilobytes is the sweet spot and 7.2 megabytes is the maximum transfer rate that this controller can deliver to this chip. But we’ll see because I can play around with this number.

[Testing different block sizes]

Alright, so that copy ended and the average transfer rate for that pass with the four-kilobyte block size was 7.3 megabytes per second. Now I’m already pretty happy with that, because without specifying the block size I was only getting 3.7 megabytes per second, and I found that a little bit odd given that this is a solid-state drive. That seemed a little bit too low, so I’m already happy with this.

Now I’m gonna try one-kilobyte block size to see if decreasing the block size causes the transfer rate to remain the same or go down or go up. Let’s see. I’m going to hit Enter right now, type in my password… oh, 3.3, 3.4. Okay, so it went down.

Alright, so let me just cancel that. It was going to remain around 3.8 megabytes, which is about the same size as before. It seems like four kilobytes is the right size. But let me go ahead and reinsert this disk again and I’m gonna go back to eight kilobytes. Let me see what eight kilobytes yields.

My guess is that four kilobytes is gonna be the sweet spot, but if it goes up to, let’s say, 10 megabytes—I don’t think so. I think the fact that these are kind of like double almost means that four-kilobyte is probably going to be the sweet spot. But let’s try with eight kilobytes and see what performance we get.

By the way, if you’re ever going to be playing around with gdd or dd in your computer, make sure that you know what you’re doing. You don’t want to accidentally overwrite an important drive. It’s a pretty dangerous tool. In my case, I’m on a Mac and I use the Disk Utility here so that I can be very, very certain that I am choosing the correct disk. I do not want to accidentally overwrite my backup, for example, or all my data.

Alright, let me hit Enter here and let’s see what transfer rate we get. Okay, six… okay, so it went down to 6.6 megabytes. So I’m gonna say that 4K is the sweet spot for this particular drive.

I think that aligns with what I was reading online—that SSDs, at least the controllers, they like to be able to transfer four-kilobyte chunks. If you send less than one-kilobyte chunks, then it probably slows down the pipeline because it’s waiting for a four-kilobyte amount of data to be received before it writes to the memory chip. If you send more than eight kilobytes, it might be pushing back on the system, which causes a delay, and that’s why we get lower performance.

Those are totally just guesses, but you know, I’m a hardware engineer, so I can kind of imagine what’s happening inside this chip over here. If I send the exact block size to this bus, then it should be able to just grab the data from the bus, write it, grab it, write it. But if it’s not—if it has to wait for one-kilobyte chunks at a time—then it might have an internal buffer of four kilobytes that has to be filled up in four cycles, four clock cycles, before it’s writing to the memory. That’s why we get slower performance.

If you send a larger block size, then potentially you’re pushing back on the bus over here while the drive writes in four-kilobyte chunks.

Those things are all just guesses, but if you have a better explanation as to why my performance is lower as I mess around with block sizes that are not four kilobytes in size, tell me in the description, because I love learning. If you have deep knowledge about these controllers and how SSD data is transferred from these controllers to the memory chip, let me know.

Alright, well I hope this was interesting. If anything, if you’re using gdd or dd, familiarize yourself with what drives you’re writing to and reading from, and play around with the block sizes because you might be able to double your performance like I did.

Alright, well let me know what your thoughts are in the comments. Thank you!