dd cloning a Win10 HDD to SSD

Tue Mar 23 13:00:01 EDT 2021

I was 20 minutes into dd when I noticed that the disks were mounted.
Aborted dd.  Unmounted both disks and restarted dd.  I'm at the tail end of
the run, and hoping it completed without errors.  If it barfs I may try
ddrescue, the gnu version.

The old disk has really bad random access rates.  It's like less than 0.5
MB/sec for random 4k access.  On Win10 it's incredibly slow.

FYI, the only reason I even turned on this sorry excuse of a laptop was the
NH VINI website would not render the Covid-19 vaccine registration site
correctly in Chromium, Chrome or Firefox in Linux yesterday.  It was
impossible to fill out the form.  After 3 hours of really slow windows
updating, I could install the latest version of Chrome on Windows 10.  Then
and only then could I register.  It took 6 hours to update the laptop to be
current.  So despite the fact that I don't use Win10 regularly, it was
useful yesterday.  The laptop experience was so painful that I decided to
replace the HDD with a spare SSD.

The State of NH made the registration forms only work with the latest
version of Edge, Chrome and Firefox.  Unfortunately, yesterday, in Linux,
the versions were slightly older.  For Firefox the Windows version was
86.0.1, and in Linux it was 86.0.  Today I noticed that 86.0.1 is available
for Linux.

Any ways, that's why I'm attempting this.  If for some odd reason I have to
use the Win10 laptop again maybe it won't be so painful.  20 minute boot
times are just awful.  An SSD should bring it to 20 seconds at least
according to a disk benchmark tool I ran.

Personally, I hope my real laptop gets repaired.  It croaked after a couple
of months.  Brand new.  In the interim, I am dd'ing with a RPI4, as that's
all I have.  The RPI boots direct from SSD and is overclocked to 2Ghz, so
it's tolerable, but not speedy.

On Tue, Mar 23, 2021, 12:19 PM Joshua Judson Rosen <rozzin at hackerposse.com>
wrote:

> On 3/23/21 9:07 AM, Bruce Labitt wrote:
> > On Tue, Mar 23, 2021 at 8:52 AM Dan Jenkins <dan at rastech.com <mailto:
> dan at rastech.com>> wrote:
> >
> >     In my experience dd works. Make sure the destination disk is larger
> than
> >     the source. I've had problems sometimes when they were the exact same
> >     size. Any other issue was due to issues on the source disk, in which
> >     case ddrescue, has worked.
>  >
> > In my case the disks report to be the same size in lsblk.
> > fdisk -l reports the hdd is 1000204886016 bytes, and the sdd
> is 1000204886016 bytes or exactly the same size.
> > Guess I will try dd.  Fingers crossed...
> If the destination disk does end up not being big enough,
> you can probably shrink the data on the source disk a little
> (and then fix up the GPT on the destination disk, if you're using GPT--
>   because GPT wants to keep a `backup table' at the _physical tail end_
>   of the disk and some implementations of GPT will refuse to read
>   the partition table if the disk doesn't pass that sniff-test).
>
> Just be sure that you don't have the source filesystem mounted writeably
> when
> you're trying to copy it like that...: it's pretty important
> that nothing be actively using a filesystem and causing the data/metadata
> stored within it to change as you try to dd a copy of its underlying
> storage.
>
> And, since I don't think anyone mentioned this: be sure to us a big enough
> blocksize
> with dd, because the default 512-byte bs will be incredibly slow
> (and I guess *could* in theory cause a lot of extra wear on the SSD
>   due to write-amplification, though I guess the Linux block layer
>   should protect against that?).
>
> For the rest of my response, I'm going to mostly ignore the "Windows 10"
> part of the question and provide guidance to people looking through the
> list archive
> for guidance doing the same sort of data-migration but for Linux disks
> (though I suspect that the underlying rationales port to other operating
> systems)...:
>
> There are theoretically reasons to make a fresh filesystem / LVM PV / RAID
> / whatever
> structure, with its configuration tuned to the native block-size of the
> underlying
> flash controller..., but in practice it never seems to matter enough to
> make it worthwhile
> to even bother figuring out what any of those numbers are.
>
> There are however real + very practical reasons to initialize storage on
> different physical disks
> with different *IDs* if you want to be able to use them together at the
> same time, e.g.:
> different ext filesystem UUIDs, or different PV IDs if you want to be able
> to use them both with LVM. You can also change those IDs after the fact.
>
> If I understand your use case, you really just have a partition table with
> one two filesystems + maybe swap space, and you're going to discard the
> data on
> the old disk (and maybe even discard the old disk) once the transfer is
> done.
> Taking both disks out of use and just dd-ing from one to the other should
> be
> fine for that--though, when doing such a migration for Linux systems, you
> might want
> to consider setting the new disk up with LVM (and then dd'ing from the
> _partitions_
> on the source disk into the _Logical Volumes_ on the destination disk),
> so that things like this are easier next time.
>
> (one of the many nice things about LVM, even if you're only going to have
> one disk `right now',
>   is that it makes disk-migrations like this *really easy*: you just plug
> the new
>   disk in, ensure that it has been initialized as a PV, run "pvmove", and
> then pull
>   the old disk out when it's done--and you can keep using the filesystem
> while
>   the migration is in progress--and LVM makes it pretty straightforward to
> even
>   do things like convert a single disk into a RAID setup at some future
> point,
>   like when you're about to throw the old disk out and decide that it'd be
> more useful
>   as a hot spare than as landfill).
>
> --
> Connect with me on the GNU social network: <
> https://status.hackerposse.com/rozzin>
> Not on the network? Ask me for an invitation to a social hub!
> _______________________________________________
> gnhlug-discuss mailing list
> gnhlug-discuss at mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.gnhlug.org/pipermail/gnhlug-discuss/attachments/20210323/01e94d8d/attachment.html 