Date: Wed, 31 Aug 2016 23:09:38 -0500 (CDT) From: "Valeri Galtsev" <galtsev@kicp.uchicago.edu> To: "Kevin P. Neal" <kpn@neutralgood.org> Cc: "Christoph P.U. Kukulies" <kuku@kukulies.org>, "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org> Subject: Re: dd blocksize when copying to SSD disk Message-ID: <53010.69.209.232.121.1472702978.squirrel@cosmo.uchicago.edu> In-Reply-To: <20160831184925.GA80454@neutralgood.org> References: <b2926488-b93b-9586-898e-1ec697529a97@kukulies.org> <20160831184925.GA80454@neutralgood.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Valeri > > 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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "freebsd-questions-unsubscribe@freebsd.org" > ++++++++++++++++++++++++++++++++++++++++ Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247 ++++++++++++++++++++++++++++++++++++++++
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53010.69.209.232.121.1472702978.squirrel>