Hi Scott, Please don't 'dd' onto an entire SSD. Here's why:
SSDs use logical block addressing (LBA) just like all other drives, but there is an abstraction layer called the Flash Translation Layer (FTL) that separates LBA from the actual physical address space on the flash chips that store the data. When actual data in use by the filesystem is being written, this works out alright, but when blocks that are unused on the source get copied, they get written too, and as Ed and Robert mentioned, the SSD doesn't actually know that those are blank, it thinks they're in use, and if it thinks that those blocks are in use, it won't garbage collect them, or use them for wear leveling, all of which happens on the back end of the controller and you never see. Also, something that you should know, is that even though disks might have an LBA size of 512 bytes, all modern consumer hard disk drives have 4k block sizes, not 512b, and it's not actually uncommon for SSDs to have 1MB (or bigger) "write blocks". In the case of linear writing, like a 'dd', it wouldn't actually affect it so much (probably - this is very much a firmware-determined behavior), since most SSDs can actually append to the same write block without re-writing all of it. If you want to check out more of it, I taught a 3-hour class on disk technology at LOPSA-East a little bit ago and put the video on YouTube: https://www.youtube.com/watch?v=G3wf1HMr6b0 It's far better to use a file-level copy, as most people have suggested. On the off-chance you have already used dd to image onto an SSD (it's probably going way slower than it would be otherwise), you can "fix" it by running a user-land TRIM utility that scans reports unused blocks as free to the SSD using the Discard command. I don't actually know of one that runs in OSX userspace, though. And in case you missed it, Apple just made it MUCH more of a PITA to install after-market SSDs in Macs: http://hothardware.com/News/AntiCompetitive-Apple-Disables-Trim-Support-On-3rd-Party-SSDs-In-OS-X/ --Matt On Fri, Nov 21, 2014 at 5:57 PM, Scott Classen <[email protected]> wrote: > what about dd? > > dd if=/dev/sda of=/dev/sdb bs=512 conv=noerror,sync > > > > > On Nov 21, 2014, at 1:53 PM, Tim Shubitz <[email protected]> wrote: > > > > Morgan, > > I’m a Carbon Copy Cloner fan. > > > > Not the cheapest tool but it’s really well done. > > > > > > - tim > > > > > >> On Nov 21, 2014, at 3:38 PM, Morgan Blackthorne <[email protected]> > wrote: > >> > >> I'm picking up an SSD for my MacBook since I caught a pre-Black Friday > sale. What's the best way to clone things over to the new drive... toss > both in my Linux box and use dd, or is there a better way? ISTR that HFS is > somewhat problematic. > >> > >> Or should I put it into an external enclosure and use Time Machine? > >> > >> _______________________________________________ > >> Discuss mailing list > >> [email protected] > >> https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss > >> This list provided by the League of Professional System Administrators > >> http://lopsa.org/ > > > > _______________________________________________ > > Discuss mailing list > > [email protected] > > https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss > > This list provided by the League of Professional System Administrators > > http://lopsa.org/ > > _______________________________________________ > Discuss mailing list > [email protected] > https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss > This list provided by the League of Professional System Administrators > http://lopsa.org/ >
_______________________________________________ Discuss mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/discuss This list provided by the League of Professional System Administrators http://lopsa.org/
