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