dd blocksize when copying to SSD disk

Valeri Galtsev galtsev at kicp.uchicago.edu
Thu Sep 1 04:36:00 UTC 2016

On Wed, August 31, 2016 1:49 pm, Kevin P. Neal wrote:
> On Wed, Aug 31, 2016 at 06:35:28PM +0200, Christoph P.U. Kukulies wrote:
>> I'm about to copy an existing Windows 7 system to an SSD. Source drive
>> is a hard disk of 256 GB, destination drive a 500 GB Samsung SSD 850
>> EVO.
>> Given the fact that unnecessary write operations to SSDs should be
>> avoided I'm thinking about the best strategy to use dd to write to the
>> SSD.
> I'm not sure that dd is the best strategy. Using Windows to do the copy
> may be better.

Agree. When I have to transfer MS Windows onto different drive, I boot
into windows, do so called "image backup", it also asks to create boot
disk (whichever they call it, MS is good at reshuffling names of yet same
tools, etc), then I replace drive, boot off that disk and have whatever
media image backup was created on attached, and just recover from that
image. Note, that this only will works to have system running on the same
hardware (which you do). One can use this to replicated system for
multiple machines similar way, but one needs for that prep system before
imaging, and then upon booting of each replica one needs to go through
registration of this separate copy of Windows - with separate keys or
whichever way your licenses of windows work.


> Current SSDs use the TRIM command (part of the wire protocol) to know
> which blocks are in use and which are free. This is to make wear leveling
> easier. *waves hand* (The reasons are more complicated than that, but
> nevermind for today's purpose.)
> If you use the dd command then the SSD will believe the entire first half
> of the disk is in use despite there being blocks that Windows knows are
> not used. This may result in more wear on the drive than if you used
> Windows to do the copy.
>> The disk has a capacity (from linux-fdisk): of 500.1 GB (500107862016
>> bytes)
>> That's 976773168 sectors.  It has reportedly 60801 cylinders ( 255
>> heads, 63 s/t gives 16065 sectors/cyl).
>> When I calculate 976773168 / 60801 I'm getting 16065.0839... sectors  /
>> cyl - why this uneven number? Is there an incomplete track left over?
> What's a "track" in an SSD context? If you really want to attempt to
> maximize write block size then factor the number of sectors and then
> multiply some of those factors until you get a reasonable block size.
> Then again, I'm not sure this even matters. The drive may buffer up writes
> until it gets a whole page inside the SSD. So attempting to optimize the
> write size won't gain anything.
> --
> Kevin P. Neal                                http://www.pobox.com/~kpn/
>    "I like being on The Daily Show." - Kermit the Frog, Feb 13 2001
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to
> "freebsd-questions-unsubscribe at freebsd.org"

Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247

More information about the freebsd-questions mailing list