Possible ways I Tried to Shrink Boot Disk of GCP Instance

      Comments Off on Possible ways I Tried to Shrink Boot Disk of GCP Instance

This article will walk you through the steps I followed to shrink Boot Disk of GCP Instance. This is the continuation of How to Shrink Google Cloud Instance Disk 

How to shrink Google Cloud Instance Boot Disk

Here are the steps which I followed to shrink the volume, help me out if you get where I made mistake and why I could not shrink successfully,

Step 1 :

Create a snapshot of Big disk and create a new disk out of that snapshot. At the same time create a small disk [10GB ] and attach both disks to that big instance.

Log in to the instance and check if the disk is attached,

[[email protected] ~]# lsblk 

sda      8:0    0  20G  0 disk 
└─sda1   8:1    0  20G  0 part /
sdb      8:16   0  20G  0 disk 
└─sdb1   8:17   0  20G  0 part 
sdc      8:32   0  10G  0 disk  
Step 2 :

Create directories to mount the attached disks,

# mkdir /mnt/big-disk

# mkdir /mnt/small-disk

We can clearly see that the big disk created has the root LABEL.

# blkid /dev/sdb1
/dev/sdb1: LABEL="/" UUID="823db525-82d9-467e-acdf-7379cbd8517" TYPE=“xfs"
Step 3 :

Partition our small disk same as the big disk and also we need to format it to XFS similar to the big boot disk.

Once we partitioned small disk /dev/sdc, we should run partprobe [Inform the operating system of partition table changes] like shown below,

# fdisk /dev/sdc

# partprobe 

# lsblk 

sda      8:0    0  20G  0 disk 
└─sda1   8:1    0  20G  0 part /
sdb      8:16   0  20G  0 disk 
└─sdb1   8:17   0  20G  0 part 
sdc      8:32   0  10G  0 disk 
└─sdc1   8:33   0  10G  0 part 
Step 4 :

Format the small disk to XFS like shown below,

# mkfs.xfs /dev/sdc1
# blkid /dev/sdc1 

/dev/sdc1: UUID="ab93c8f7-5297-4e51-bdd8-dec7f8ce11d6" TYPE="xfs" 
Step 5 :

Then Mount both volumes in the created mount paths,

You can easily mount newly created small disk, But while mounting big disk you will get the below error due to the Filesystem UUID,

[[email protected] ~]# mount /dev/sdb1 /mnt/big-disk/

mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail or so.

==> Soution for this error,

1, We can mount using nouuid flag,

# mount -o nouuid /dev/sdb1 /mnt/big-disk

2, Since it is XFS format we use xfs_admin to generate new UUID.

Here we are using the first method to mount the disk, before mount the disk note down the current UUID of the big disk,

# mount -o nouuid /dev/sdb1 /mnt/big-disk

# mount /dev/sdc1 /mnt/small-disk/

[[email protected] ~]# df -h

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        20G  1.6G   19G   9% /
devtmpfs        1.8G     0  1.8G   0% /dev
tmpfs           1.8G     0  1.8G   0% /dev/shm
/dev/sdb1        20G  1.7G   19G   9% /mnt/big-disk
/dev/sdc1        10G   33M   10G   1% /mnt/small-disk
Step 6 :

We have our both disks mounted, now we can use rsync command to copy each and every file to the small disk from big disk,

rsync -avHAXxSP /mnt/big-disk/* /mnt/small-disk/

This will take some time to complete, once the copy is done we should verify the checksum to find if there is any data loss,

find /mnt/big-disk/ -type f -name "*" -exec md5sum {} + | awk '{print $1}' | sort | md5sum

find /mnt/small-disk/ -type f -name "*" -exec md5sum {} + | awk '{print $1}' | sort | md5sum

Now we could see there is no data loss, the small disk has the same data as a big disk.

Step 7 :

Old boot disk’s UUID will be there inside the boot loader config files, So we should give the same UUID to the new small disk and also we should give the root Label [/],

Unmount the small disk,

# umount /dev/sdc1

Give the same old label of big disk to new small disk,

# xfs_admin -U 823db525-82d9-467e-acdf-7379cbd85171 /dev/sdc1
For ext4 :  # tune2fs /dev/{device} -U {uuid}

Now give root label to the Disk,

# xfs_admin -L / /dev/sdc1 
For ext4 : e2label /dev/sdc1 /
Step 8 :

Now detach the small disk take a snapshot from the small disk,

Step 9 :

Once the snapshot is created we can launch an instance using the snapshot and check if it works,

When we create the instance from snapshot we will get an error shown below,

I tried the same thing by creating an instance from the image created from a small disk, But instance was not booting up and does not even give any errors.

Others ways I tried :

I also tried to shrink boot volume using a tools called fsarchiver.

Basically fsarchiver is a system tool that allows you to save the contents of a filesystem to a compressed archive file. Everything is checksummed in the archive in order to protect the data. If the archive is corrupt, you just lose the current file, not the whole archive.

Using fsarchiver is very simple, it helps us to remove the complex steps we followed in the previous method.

Just follow the Steps 1 and 3 from previous method before use fsarchiver,

Create an archive using fsarchiver save,

# fsarchiver savefs -A /opt/boot_disk.fsa /dev/sdb1

In the above step filesystem will be archived in a file named boot_disk.fsa, Now we can restore it into the small disk using,

# fsarchiver restfs /opt/boot_disk.fsa id=0,dest=/dev/sdc1

this will copy everything including format and label. Then follow Step 8 and 9 in the previous method to create instances using the disk.

Using this method also I could not shrink the volume successfully, folks share your thoughts if anyone achieved this.

Sharing is caring!


I'm an IT professional having multiple years of experience in IT Infrastructure planning, System integrations, Project implementation, and delivery. DevOps Enthusiast skilled with broad ranges of technology adoption. Well versed with Cloud Computing and Application Service Offerings such as SaaS/PaaS/IaaS. Expert in aligning business goals, mission and process to architect innovative solutions and strategies.