DEV Community

Cover image for Expanding Disk Size in Google Cloud
Athreya aka Maneshwar
Athreya aka Maneshwar

Posted on • Edited on

Expanding Disk Size in Google Cloud

#googlecloud #webdev #programming #devops

Hello, I'm Maneshwar. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product.

Hi there! Right now, I’m building a first-of-its-kind tool that helps you automatically index API endpoints across all your repositories. makes it easier to discover, understand, and interact with APIs in large infrastructures.

When your VM’s root disk is running out of space — say you're on 20GB and need to go to 40GB — here’s the exact procedure to scale the disk without breaking anything. This example uses an Ubuntu VM named phpbb-new.

Step 1: Resize the Disk from Google Cloud Console

  1. Go to Google Cloud Console.
  2. Navigate to Compute Engine → VM instances.
  3. Click your instance (e.g. phpbb-new).
  4. Scroll to the "Boot disk and local disks" section.
  5. Click the boot disk name.
  6. Click EDIT at the top.
  7. Change Size (GB) → from 20 → to 40.
  8. Hit SAVE.

Note: Disk size updates immediately in GCP, but the OS inside the VM still sees the old size. You’ll need to fix that next.

Step 2: SSH into the VM

From the instance details page, hit SSH.

Confirm you’re in with:

root@phpbb-new:~#
Enter fullscreen mode Exit fullscreen mode

Step 3: Check the Current Disk Usage

Run:

df -h
Enter fullscreen mode Exit fullscreen mode

You’ll likely see:

Filesystem      Size  Used Avail Use% Mounted on
/dev/root        19G   16G  3.1G  84% /
Enter fullscreen mode Exit fullscreen mode

Then run:

sudo fdisk -l
Enter fullscreen mode Exit fullscreen mode

Check that it detects the new disk size:

Disk /dev/sda: 40 GiB
...
GPT PMBR size mismatch (old size vs new size)
Enter fullscreen mode Exit fullscreen mode

Step 4: Fix the GPT Partition Table

Let’s correct the partition table to reflect the new size.

sudo fdisk /dev/sda
Enter fullscreen mode Exit fullscreen mode

At the Command (m for help): prompt, just type:

w
Enter fullscreen mode Exit fullscreen mode

This writes the updated partition layout and exits. Ignore any "device busy" warnings — it's fine in GCP.

Step 5: Expand the Partition

Run:

sudo growpart /dev/sda 1
Enter fullscreen mode Exit fullscreen mode

This resizes partition 1 (/dev/sda1), which maps to /.

Expected output:

CHANGED: partition=1 ... new: size=83883903
Enter fullscreen mode Exit fullscreen mode

Step 6: Resize the Filesystem

Tell ext4 to use the new space:

sudo resize2fs /dev/sda1
Enter fullscreen mode Exit fullscreen mode

This might take a few seconds. When it’s done, your root filesystem now uses the full disk.

Step 7: Verify It Worked

Final check:

df -h
Enter fullscreen mode Exit fullscreen mode

You should now see:

Filesystem      Size  Used Avail Use% Mounted on
/dev/root        39G   16G   22G  43% /
Enter fullscreen mode Exit fullscreen mode

Mission accomplished.

Recap: Quick Command List 

# SSH into VM
df -h
sudo fdisk -l

# Fix GPT table
sudo fdisk /dev/sda
# then just type: w

# Resize partition
sudo growpart /dev/sda 1

# Resize filesystem
sudo resize2fs /dev/sda1

# Verify
df -h
Enter fullscreen mode Exit fullscreen mode

Pro Tips

  • Works only for disks using GPT (which is default in GCP).
  • If your root disk is XFS instead of ext4, use xfs_growfs / instead of resize2fs.
  • For automated workflows, you can script this and run via cloud-init or startup scripts.

Done. Disk doubled. No reboot. No downtime.

helps you get all your backend APIs documented in a few minutes.

With , you can generate interactive API docs that allow users to search and execute endpoints directly from the browser.

If you're tired of updating manually or syncing collections, give it a shot.

git-lrc
*AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.*

Any feedback or contributors are welcome! It's online, source-available, and ready for anyone to use.

⭐ Star it on GitHub:

GitHub logo HexmosTech / git-lrc

Free, Unlimited AI Code Reviews That Run on Commit

git-lrc logo

git-lrc

Free, Unlimited AI Code Reviews That Run on Commit


git-lrc - Free, unlimited AI code reviews that run on commit | Product Hunt

AI agents write code fast. They also silently remove logic, change behavior, and introduce bugs -- without telling you. You often find out in production.

git-lrc fixes this. It hooks into git commit and reviews every diff before it lands. 60-second setup. Completely free.

See It In Action

See git-lrc catch serious security issues such as leaked credentials, expensive cloud operations, and sensitive material in log statements

git-lrc-intro-60s.mp4

Why

  • 🤖 AI agents silently break things. Code removed. Logic changed. Edge cases gone. You won't notice until production.
  • 🔍 Catch it before it ships. AI-powered inline comments show you exactly what changed and what looks wrong.
  • 🔁 Build a habit, ship better code. Regular review → fewer bugs → more robust code → better results in your team.
  • 🔗 Why git? Git is universal. Every editor, every IDE, every AI…


View on GitHub


Top comments (1)

Collapse
 
shiva_shanker_k profile image
shiva shanker • • Edited

Honestly, there's gotta be a simpler way than all these manual steps! What about just using Google Cloud's auto-resize feature or setting up disk monitoring with alerts?
Sometimes the "simple" solution is just avoiding the problem entirely.what's your opinion in this!!