Cloning from HD to SSD

So I just picked up this sweet deal for $139:

The plan is to clone my 1TB hunk of spinning rust (with Fedora 29 onboard) to the new SSD with dd. I’ve heard this can be a problem with NVME drives, but my new acquisition is SATA. Will I have any problems doing this?

I have moved my archlinux installation from HDD to SSD (both SATA) without problems. I recommend you boot up a live system with GParted and copy & paste the partitions.

dd seems excessive, but as long as new ssd is bigger than old hdd then in general it should work

you might have to do something to make it boot, depending on bios/mbr vs uefi/gpt

I would prefer to understand the partition layouts and geometries and adjust as required, because you might be copying from an 512byte sector aligned partition to a 4kb or 8kb sector aligned ssd, and just doing a bulk copy with dd will perpetuate the misalignment, and mean that all subsequent IO on the ssd will be misaligned and each block IO may result in multiple IOs to compensate.

From a live CD, I woud setup the correct partition alignments, copy each partition, install grub boot sectors etc, and make sure /etc/fstab on the new disk is correct.

Probably a good idea not to have the old disk plugged in when you boot the new disk for the first time, especially if you have duplicated with dd and thus have duplicate UUIDs on your partitions.

Good advice. I had forgotten about the UUIDs, though what I usually do in that scenario is edit /etc/fstab to point to /dev/sdX instead of the UUID.

I heard that your SSD will wear out much faster if you clone the partition.

i want sources on this a quick google finds nothing but the normal write degradation. please more info? pm if you want… as its not relevant to post

1 Like

While it may not be relevant to the original question, I’d also like to know if this is true. Please post if you find out something.

1 Like

@anon57598049 @imrazor
I’m not well-versed with this and I can give a (hopefully) basic explanation

I’ve read about how SSDs and HDDs have different partition alignments, and merely cloning it will cause a misalignment can cause the SSD to write 2x as much (I think), and affect it’s performance.

I hope someone who knows more about this to give more details

Edit: found this article. I think this might explain things a whole lot deeper

1 Like

So I went ahead and cloned the drive with dd. It boots fine, but seems a bit slow for an SSD (even a SATA III model.) How would I go about verifying the partition alignment?

> fdisk -l /dev/sdb
> Disk /dev/sdb: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 4096 bytes
> I/O size (minimum/optimal): 4096 bytes / 4096 bytes
> Disklabel type: gpt
> 
> Device         Start        End    Sectors   Size Type
> /dev/sdb1       2048    1050623    1048576   512M EFI System
> /dev/sdb2    1050624  118237183  117186560  55.9G Linux filesystem
> /dev/sdb3  118237184  180738047   62500864  29.8G Linux swap
> /dev/sdb4  180738048 1953523711 1772785664 845.3G Linux filesystem

Looks like the block size is 4k, but the first partition starts at 2048. So…not aligned? Can this be tweaked with gparted from a live USB? Hopefully without a full reinstall…

returning for the article if you have it or not?
looking into partition alignments unless your block size on the the start of the block hdd sets it to 63 and ssd’s normally 64
unless the block size of data is on the i/o package 4096 comeback as 4096 bytes you are fine and the blocks are aligned which from @imrazor has no issue. ( the start block would have come out a decimal but you set the block to 2048 no issue though)

this issue if from the older days when consumer ssd’s where 32-64gb and a few 100$'s of dollars if not more. but most modern cloning software now accounts for this and checks for things on the drive that state its a ssd vs a hdd to set the writen block at the correct location to keep the ssd loading correctly…

Hold the fuck up, did that work? No dd? No Rsync? You just copy and pasted that thing?

Yeah, I was dumbstruck as well when I first saw this. You can literally select the Partition in GParted, Ctrl+C, Ctrl+V and that’s it.

2 Likes

Holy shit this is amazing.

Now I know how to quickly and easily move my current install to a new larger SSD in the future. You sir, if we are ever lucky enough to be in physical proximity, deserve a drink.

2 Likes

Even dd? The HDD and the SDD had exactly the same size and geometry, so I just dd’d it. Googling for partition alignment got me all kinds of misinformation, so I was hoping for some clarity.

I detached the HDD after cloning and everything booted up; I didn’t even have to edit /etc/fstab. But Fedora 29 seems to boot much slower than Windows 10 does on my Samsung 860, which is why I was concerned the new one might be out of alignment.

1 Like

the blocks would show a decimal point due to the block on a hdd starting at 63/4096=65.0158730159 64/4096=64 the blocks are aligned you already confirmed its fine. ssd’s start their blocks on 64 so no decimal point would be made i’m mostly restating what ive learned from reading but its a nonissue in todays tech

any article i can find on this is from 2011 or before
image

1 Like

even better than using CP to clone a disk is PV. it’s actually faster and gives you a progress bar.

I apologize. I honestly thought I linked the article.

I got some of my information from this

1 Like

Same one I posted pic about! No worries I kinda guessed that from the way the post was. Thanks for still raising my curiosity

1 Like

one thing i would recommend though is to put your home, temp, and var partitions on an hdd as these partitions will have multiple write and rewrites over the normal lifetime.
While ssd is indeed faster the have a limited write cycle lifetime.
put your os files on the ssd as they are read only (with exception of updates)
this will give you a much greater lifespan of your equipment

Modern SSD endurance is far beyond what just about any consumer will use unless they are expecting to use the same drive for well over a decade.

The spec sheet for the Crucial MX500 the OP purchased lists the endurance as 360 TB written, which equates to 197.26 GB written every single day for five years straight. If writing 50 GB per day, which I still find to be quite a lot to do every day for a consumer, it would equate to 19.73 years.

image