dd cloning a Win10 HDD to SSD

Tue Mar 23 13:47:02 EDT 2021

Worked on the first boot.  Booted in maybe 10 seconds!  Ran CrystalDiskMark
on the before and after.  It's the random 4k stuff that really makes a
difference.
The Samsung EVO860 SSD is a minimum of 77x faster on random write and 100x
faster on random read as compared to the WD HDD.  (RND4K, Q1T1).  It's like
a totally different machine.  Hope windows won't complain later.

So... for the record, dd did work to clone a Win10 disk to a SSD.  It
copied over all 5 partitions, including the MS secret partition and EFI,
plus whatever nonsense partitions that Dell put on this disk.  Will check
to see if all this survives a reboot...  Yes!
Well, hot diggity dog!  At least for this disk pair, dd worked great!  No
BS, no FUD, it just worked. :)

On Tue, Mar 23, 2021 at 1:00 PM Bruce Labitt <bdlabitt at gmail.com> wrote:

> 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/f61767d4/attachment-0001.html 