On 3/23/21 9:07 AM, Bruce Labitt wrote: > On Tue, Mar 23, 2021 at 8:52 AM Dan Jenkins <d...@rastech.com > <mailto:d...@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@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/