Change btrfs Filesystem Block Size While Migrating Ubuntu 18.10 Environment to Larger SSD?

Question

I have a 500 GB SSD in my laptop with a partition holding Windows 7 and a second partition holding Ubuntu 18.10 installed on a BTRFS filesystem with a 4KB block size and dual boot.

I have a 1 TB SSD that I am installing in my desktop pc, and I want to make a complete copy of my laptop's current Ubuntu 18.10 (BTRFS filesystem) partition onto this 1 TB SSD for my desktop. I do not want windows on my 1TB SSD and desire the entire 1TB SSD to single boot Ubuntu 18.10. When I log into the OS on the new SSD after copying: I want access to all of my installed software (installed via sudo, pip, and .deb files), all of my settings and software configuration, and all of my bookmarks.

However, I want to make a fresh install of Ubuntu 18.10 with an optimal blocksize for my desktop's 1 TB SSD, 64 GB ram and i7-6700k processor.

Is is possible to copy / clone a customized Ubuntu 18.10 OS with BTRFS filesystem and 4KB block size onto a freshly installed 18.10 OS with BTRFS filesystem and (say) 4096KB block size (if 4096KB is optimal for my PC)?

I want everything to be the same on both OS's. Do I need to do a manual install of each software item from scratch / or can I do something like Clonezilla or Mounting my laptops directories directly to my 1TB SSD?

Answer 1

There are many potential technical problems with attempting this transfer. To make a exact copy you would probably use Clonezilla or dd, however you would likely run into UUID conflict if having both disks plugged in at the same time which could destroy data. AFAIK This UUID clone conflict is only a problem with BTRFS and has something to do with the OS thinking the two disks are a RAID array, or not knowing which disk to write data back two leaving the journal out of sync and unclean on shutdown.

This task would be better suited for a Arch system. There may be a difference in partition layout - MFT vs GPT, if it is MFT bootloader data will have to be written to the beginning of the disk by chrooting the new disk and running apt or dpkg-reconfigur grub2 or whatever boot loader you use.

And then there is the problem of in /etc/fstab each btrfs subvolume has a different subvolume ID, so if you were to solve the 4k problem by manually setting the layout on the new disk and trying to rsync all the data, the sub-volume IDs would be different requiring you to know exactly where to change them in the filesystem.

I suggest you disconnect your old disk, and install a fresh ubuntu. And then locate commands to generate a list of all packages installed via apt, and all packages installed via pip, and run a command to reinstall all of those.

After that is done, I suggest rsyncing your /home directories, and assuming that covers 99.9% of your important data, keep the other disk in it's current state to pull anything you missed off of it later.

To my knowledge, the KB sector size of the disk shouldn't really effect performance, but don't quote me on that.

That's the information I would begin to consider when finding the answer to your own problem.

Answer 2

For the UUID problem stated above you can use: btrfstune -U <UUID> /dev/sdx1 to change the UUID of any btrfs partition on any drive.

For the subvolume id it depends on how you set up your btrfs filesystem. If you followed Ubuntu's standard layout i.e. a @ subvolume for root and a @home subvolume for home then the UUID is the same. For example my /etc/fstab:

# /dev/sdb1 - / (root) UUID=59736ffd-b777-4ee1-af45-11cdf76353d4 / btrfs defaults,subvol=@,noatime 0 0

# /dev/sdb1 - /home UUID=59736ffd-b777-4ee1-af45-11cdf76353d4  /home btrfs   defaults,subvol=@home,noatime 0 0

Using rsync works fine as I back my system up to a ext4 partition, completely create a new btrfs filesytem on another drive, then used btrfstune to change my UUID to what it was before, then copied everything over to the btrfs drive using rsync. Note that it's only necessary to use btrfstune if you want the same UUID (don't have to mess with /etc/fstab). If it doesn't matter to you just change it in /etc/fstab to you current UUID. Whether you use MBR to boot or UEFI to boot DOES make a big difference. I use UEFI.