Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 30 Jan 2017 11:46:15 -0800
From:      David Christensen <dpchrist@holgerdanske.com>
To:        freebsd-questions@freebsd.org
Subject:   Re: FreeBSD 11.0-RELEASE-p7 i386 system drive imaging and migration
Message-ID:  <455f87f9-3f1d-dc68-ac1d-8248a7e0f043@holgerdanske.com>
In-Reply-To: <alpine.BSF.2.20.1701300827260.85129@wonkity.com>
References:  <df0c81d7-fd2b-852f-4007-5fb4b24100e0@holgerdanske.com> <86bmupg0gi.fsf@WorkBox.homestead.org> <2973d1ea-202f-60fa-2930-eec05b626cfb@holgerdanske.com> <alpine.BSF.2.20.1701292221150.71961@wonkity.com> <f44805f3-fd1c-e5e9-5d61-5360a3b1469a@holgerdanske.com> <alpine.BSF.2.20.1701300827260.85129@wonkity.com>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On 01/30/17 07:28, Warren Block wrote:
> On Sun, 29 Jan 2017, David Christensen wrote:
>
>>> Writing SSDs with dd is not good, limiting their wear leveling.
>>
>> That's why I used zcat rather than dd for writing to the cloned SSD.
>> If/when I know enough to use zfs send/ receive, that will be best.
>
> zcat is no different than dd in this case.  When you write a binary
> image, the SSD can't tell which blocks are truly in use, because they
> have all been written.

Taking the image with 'dd' will grab all blocks -- in-use, used, never 
used (zero-freed and available for writing).  On restoration, it all 
gets written.  Yes, it's wasteful.  But it's 2+ steps I can do by hand 
off the top of my head; rather than 18+ steps, most of which I've never 
done.


I used 'zcat' in the hope that many 512 byte blocks would be sent to the 
SSD per system call, rather than 'dd' making one system call for each 
and every 512 byte block.  (I also experimented with 'bs=1M', but adding 
'conv=sync' resulted in a bad destination image.)  Given the 
microcontroller and RAM buffer in the SSD, it might not matter.


David




Want to link to this message? Use this URL: <http://docs.FreeBSD.org/cgi/mid.cgi?455f87f9-3f1d-dc68-ac1d-8248a7e0f043>