Home / ubuntu / Questions / 615852
Accepted
GhostCat
Asked: 2015-04-30 04:57:14 +0800 CST

Moving to ssd: do a fresh install; or is "dd" of old hdd "good enough"?

  • 772

our generous management considers handing out SSDs to replace the HDDs in our laptops.

I am told that SSDs will have the same size as the HDDs; so I am now wondering: should I simply use "dd" to copy my existing xubuntu 14.04 installation (and maybe then, afterwards do the tunings listed for that related question)?

Or are there any major "technical" advantages in doing a "completely fresh" installation of xubuntu on that SSD?

In other words: will doing such a "full binary" copy have any negative effects regarding SSD performance, caching ... ?

EDIT no. 2: my current installation was created using the "default" ubuntu installer; meaning it uses LUKS and LVM. Providing some low level information:

sudo pvs

  PV                     VG         Fmt  Attr PSize   PFree 
  /dev/mapper/sda5_crypt xubuntu-vg lvm2 a--  465,52g 44,00m

sudo lvs

  LV     VG         Attr      LSize   Pool Origin Data%  Move Log Copy%  Convert
  root   xubuntu-vg -wi-ao--- 449,83g   
  swap_1 xubuntu-vg -wi-ao---  15,64g

sudo fdisk -lu

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 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
Disk identifier: 0x00079ee9
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      499711      248832   83  Linux 
/dev/sda2          501758   976771071   488134657    5  Extended
Partition 2 does not start on physical sector boundary.
/dev/sda5          501760   976771071   488134656   83  Linux

Disk /dev/mapper/sda5_crypt: 499.8 GB, 499847790592 bytes
255 heads, 63 sectors/track, 60769 cylinders, total 976265216 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
Disk identifier: 0x00000000

Disk /dev/mapper/sda5_crypt doesn't contain a valid partition table

Disk /dev/mapper/xubuntu--vg-root: 483.0 GB, 483003465728 bytes
255 heads, 63 sectors/track, 58721 cylinders, total 943366144 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
Disk identifier: 0x00000000

Disk /dev/mapper/xubuntu--vg-root doesn't contain a valid partition table
Disk /dev/mapper/xubuntu--vg-swap_1: 16.8 GB, 16793993216 bytes
255 heads, 63 sectors/track, 2041 cylinders, total 32800768 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
Disk identifier: 0x00000000

Disk /dev/mapper/xubuntu--vg-swap_1 doesn't contain a valid partition table

cat /etc/fstab

...
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/xubuntu--vg-root /               ext4    errors=remount-ro 0       1
# /boot was on /dev/sda1 during installation
UUID=b58b2697-1bf2-4ad3-80bd-4dee61e63fe4 /boot           ext2    defaults        0       2
/dev/mapper/xubuntu--vg-swap_1 none            swap    sw              0       0
hard-drive

2 Answers

  1. Best Answer

    If the two drives have the same size, cloning the source drive to the target drive using dd will have the exact same impact a full write of the target disk would have.

    Before even starting to consider whether this is a problem or not, if you need everything you have already on the old drive and this is "full enough", there shouldn't even be more questioning: dd will save you lots of time without wearing off the target drive much more than how a clean installation would have done.

    That being said, a full write of the target disk done once is not significant. Not even a second one and a third one would be.

    A MLC commercial SSD is going to surive between 2000-3000 full writes. Not to speak about SLC SSDs.

    What is relevant instead is how you will use the new drive over time. If the SSD is going to be subjected to a great number of Program/Erase cycles (e.g. creation / deletion / creation of files), its lifespan is going to decrease drastically.

    So to sum up, I'd blindly go for the dd solution and rather pay attenction on how to not decrease its lifespan by making a clever use of it over time.

    • 3

  2. There is a good chance to move all the data using LVM tools. There is short info on how to do it:

    1. Get USB connector for your SSD disk and attach it to your laptop with SSD connected

    2. Repartition your devices same way as your current disk (actually doesn't matter how, but your new LUSK partition should be same or bigger than your current LUKS partition

    3. Copy your boot folder partition to new SSD partition. If your SSD detected as /dev/sdb you can follow this steps:

      sudo mkfs.ext2 /dev/sdb1

      sudo mount /dev/sdb1 /mnt

      sudo rsync -a /boot/* /mnt/

      sudo umount /mnt

    4. Setup crypt partition on your /dev/sdb2 (second partition of new SSD disk) and attach it to your current VG (LVM volume group)

      sudo cryptsetup -y luksFormat /dev/sdb2

      sudo cryptsetup luksOpen /dev/sdb2 crypt_ssd

      sudo vgextend xubuntu-vg /dev/mapper/crypt_ssd

    5. Move physical data from your current physical partition to new SSD physical partition (be sure it can be long, ensure you have strong USB connection to your SSD, NO INTERRUPTIONS should be happened)

      sudo pvmove /dev/mapper/sda5_crypt

    It will automatically move all the data to your free SSD encrypted physical partition.

    1. Since all the moving will be online you should check new UUID of boot partition

      sudo blkid

    Find there /dev/sdb1 (your new boot partition) and edit /etc/fstab /boot UUID entry accordingly (yes, all the files already on new SSD disk, next time you can boot only with this disk attached)

    1. Remove old disk from volume group

      sudo vgreduce xubuntu-vg /dev/mapper/sda5_crypt

    2. Cross your fingers and reboot (I did about ten such movings, but without using LUKS, as I see your should enter password at boot to open your devices

    Don't do that if you don't know anything about LUKS or LVM, it's just recommendations, feel free to ask something more or consult with your engineer. I don't want you to make loss of any data. I suggest this way because dd for 500G device really not good. There is almost same question there How to migrate an encrypted LVM install to a new disk but they created new LVM VG and copy data using rsync (pvmove move data using blocks, not files - in other words pvmove really faster and will not corrupt any permissions, bits and etc). And I think where will be need of some edit of /etc/crypttab, but believe no need to do that. Please backup all of necessary data and get live-cd or usb before this move.

    EDIT:

    By the way, answering on your primary question I can say there was a bug about two years ago that tearing data with pvmove on SSD link. If you have no problems and you not borried to do fresh install it's actually way too, to safe you from any disasters.

    • 2