On Sat, Nov 22, 2014 at 10:25 AM, Ed <[email protected]> wrote: > On Fri, Nov 21, 2014 at 3:57 PM, Scott Classen <[email protected]> > wrote: >> what about dd? >> >> dd if=/dev/sda of=/dev/sdb bs=512 conv=noerror,sync >> >> > > avoid dd with SSD drives as the wear leveling will only see the one > big block, which defeats the function of wear leveling. You want to > use something like scp so the drives wear leveling will work on the > many individual files - ie for SSD drives, many small is better than > singular big for leveling.
I don't think this will work out the way that you are implying. First of all, he is explicitly giving a block size of 512 bytes. So at the OS level, each disk block is going to be presented to the OS as a separate write. Some block coalescing in the OS might take place before that stream of requests hits the SSD, but it is still going to see a lot of separate writes. If your original disk isn't highly fragmented, that coalescing is for the most part going to be blocks from the same file if it is of any great size. Using a file level copy program (scp, cp, cpio -p, etc.), is going to be subject to coalescing in the OS as well. If your source disk isn't full, the real reason to do a file level copy is because you will only copy the blocks that are actually allocated. This will probably save a lot of time with large capacity drives and will cause less wear on an SSD. Admittedly there will be lots of meta data updates as well which might create more writes, but I suspect that in the end a file copy will be better. Even better from a performance/wear perspective might be a copy program that understood the filesystem layout and only copied allocated blocks between the two disks. Now, if he is planning on changing the size of the filesystem at the same time as the copy, it gets more complicated. "dd" won't do it and you would need a pretty smart program to modify the filesystem size while copying the disk blocks directly. In this case, a file level copying program might be your only option. I have no experience with it, but the Mac Disk utility can apparently resize a filesystem which might be useful in this scenario. Its clone option (mentioned by an earlier poster) sounds like it would be worth investigating. Bill Bogstad _______________________________________________ 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/
