Date: Wed, 31 Aug 2016 15:59:43 -0600 (MDT) From: Warren Block <wblock@wonkity.com> To: "Christoph P.U. Kukulies" <kuku@kukulies.org> Cc: "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org> Subject: Re: dd blocksize when copying to SSD disk Message-ID: <alpine.BSF.2.20.1608311553400.51226@wonkity.com> In-Reply-To: <b2926488-b93b-9586-898e-1ec697529a97@kukulies.org> References: <b2926488-b93b-9586-898e-1ec697529a97@kukulies.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 31 Aug 2016, 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. That is a strange conclusion to that sentence. dd(1) writes to every block, whether in use or not. As far as the SSD is concerned, blocks that have been written to are "in use" and can't be used for wear leveling. So... don't use dd if it can be avoided. If you must, be sure to leave some unwritten space on the SSD. But I would recommend using Clonezilla to copy the disk, or a utility from the SSD vendor. Clonezilla only copies blocks that are actually used by the filesystem. > 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? Blocks per track vary on modern drives, and doesn't apply at all on SSDs. Think of it as a pool of blocks. > After all, what would be the appropriate "bs"-parameter for the dd-command? For an SSD, anything between 64K and 8M would work. Smaller values too, but they would be unnecessarily slow. This has nothing to do with actual block size any more, which does not really apply to SSDs anyway. The bs= value is essentially a buffer size. > What about socalled "alignment"? Alignment is a thing with hard drives, because they have moving parts. Align partitions to 4K or 1M boundaries on SSDs and forget about it.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.20.1608311553400.51226>