Three Tools, One Job — Which One Should You Reach For?
Every time I spin up a new server or add a disk, I get the same question from teammates: “Should I use fdisk, parted, or gdisk?” The honest answer is that all three can get you through most partition tasks — but they have real differences that matter depending on your disk size, partition table type, and whether you prefer interactive menus or scriptable one-liners.
This guide walks through each tool, compares them side by side, and shows you exactly which one to grab in which situation — with commands you can run right now.
Approach Comparison: fdisk vs gdisk vs parted
Before touching a single disk, it helps to understand what each tool was designed for.
fdisk — The Classic, With Caveats
fdisk has been around since the early Unix days. It works well for MBR (DOS) partition tables and is universally available on every Linux distribution. The catch: older versions of fdisk (pre-2.26) do not handle GPT properly, and even modern versions have limited GPT support compared to the other two tools. For disks under 2TB with a legacy setup, fdisk is perfectly fine. Go beyond that, and you’re in the wrong tool.
gdisk — fdisk’s GPT-Native Cousin
gdisk was built specifically for GPT partition tables. The interface is almost identical to fdisk — same menu-driven flow, same command letters — which makes it easy to switch. It handles GPT natively, supports disks over 2TB, and can also convert MBR tables to GPT (with care). If you’re working on modern servers or NVMe drives, gdisk is the go-to.
parted — The Scriptable Powerhouse
parted supports both MBR and GPT, handles disks of any size, and — critically — works non-interactively. You can chain commands in a single shell line, which makes it ideal for automation, cloud-init scripts, and Terraform provisioning. On my production Ubuntu 22.04 server with 4GB RAM, I found this approach significantly reduced processing time when provisioning multiple data disks during deployments, because I could run parted commands in a script without waiting for interactive prompts.
Pros and Cons
fdisk
- Pros: Available everywhere, familiar interface, great for MBR disks, no extra package needed
- Cons: Limited GPT support, no scripting-friendly non-interactive mode by default, 2TB disk limit on older versions
gdisk
- Pros: Full GPT support, MBR-to-GPT conversion, familiar fdisk-style interface, handles large disks
- Cons: Not always pre-installed (needs
gdiskpackage), MBR support is secondary
parted
- Pros: Both GPT and MBR, non-interactive mode for scripting, resize support, widely available
- Cons: Syntax is different from fdisk/gdisk, fewer safety prompts (easier to make mistakes), no GUID-specific operations like gdisk has
Recommended Setup
Here’s the mental model I use daily:
- MBR disk, interactive work →
fdisk - GPT disk, interactive work →
gdisk - Any disk, scripting/automation →
parted - Resizing partitions →
parted(only tool of the three with aresizepartcommand)
For new servers in 2024+, almost everything is GPT. I default to parted for scripted provisioning and gdisk when I need to manually inspect or repair a partition table.
Implementation Guide
Listing Disks and Current Partition Tables
Always start by identifying your disk:
# List all block devices
lsblk -f
# Show detailed partition table info
sudo parted -l
# Check if disk uses GPT or MBR
sudo fdisk -l /dev/sdbCreating a GPT Partition Table with parted
Assuming the target disk is /dev/sdb and currently empty:
# Create GPT table
sudo parted /dev/sdb mklabel gpt
# Create a single partition using all space
sudo parted /dev/sdb mkpart primary ext4 0% 100%
# Verify
sudo parted /dev/sdb printFor a more controlled setup with multiple partitions:
# 20GB first partition, rest as second
sudo parted /dev/sdb mkpart primary ext4 1MiB 20GiB
sudo parted /dev/sdb mkpart primary ext4 20GiB 100%Creating a GPT Partition with gdisk (Interactive)
sudo gdisk /dev/sdbInside the gdisk menu:
GPT fdisk (gdisk) version 1.0.8
Command (? for help): n # new partition
Partition number: 1
First sector: (press Enter for default)
Last sector: +20G # or +100% for all space
Hex code or GUID: 8300 # Linux filesystem
Command (? for help): w # write and exit
Do you want to proceed? (Y/N): YCommon partition type codes for gdisk:
8300— Linux filesystem8200— Linux swap8e00— Linux LVMfd00— Linux RAIDef00— EFI System partition
Creating an MBR Partition with fdisk
sudo fdisk /dev/sdbCommand (m for help): o # create new MBR table
Command (m for help): n # new partition
Partition type: p # primary
Partition number: 1
First sector: (Enter)
Last sector: +20G
Command (m for help): t # change partition type (optional)
Hex code: 83 # Linux
Command (m for help): w # writeFormatting After Partitioning
After creating partitions, format them. The kernel usually picks up the new partition table, but run partprobe if it doesn’t:
sudo partprobe /dev/sdb
# Format as ext4
sudo mkfs.ext4 /dev/sdb1
# Or xfs (better for large files)
sudo mkfs.xfs /dev/sdb1
# Mount and add to fstab
sudo mkdir /mnt/data
sudo mount /dev/sdb1 /mnt/data
# Get UUID for fstab entry
blkid /dev/sdb1Resizing a Partition with parted
This is where parted really stands out. Say you want to extend /dev/sdb1 to use all available space:
# First, check current layout
sudo parted /dev/sdb print
# Resize partition 1 to fill the disk
sudo parted /dev/sdb resizepart 1 100%
# Then resize the filesystem (ext4 example)
sudo resize2fs /dev/sdb1For XFS, you resize the filesystem after mounting it:
sudo xfs_growfs /mnt/dataFixing a Corrupted GPT Table
GPT actually stores two copies of the partition table — one at the start of the disk and one at the end. If one is corrupted, gdisk can recover from the backup:
sudo gdisk /dev/sdb# gdisk will warn about GPT problems
# Use the recovery menu
Command (? for help): r # recovery and transformation
Recovery/transformation menu:
b # use backup GPT header (from end of disk)
c # load backup partition table from disk
d # use main GPT header (from start of disk)
# After selecting, write the repaired table
Command (? for help): wFor MBR corruption, fdisk can rebuild the table if you know the original partition layout. Alternatively, testdisk (separate package) is excellent for automated partition recovery.
Converting MBR to GPT
If you need to convert an existing MBR disk to GPT without losing data (useful when you hit the 2TB limit or need more than 4 primary partitions):
sudo gdisk /dev/sdb# gdisk detects MBR and offers conversion
Found valid MBR and corrupt GPT. Which do you want to use?
1 - MBR
2 - GPT
3 - Create blank GPT
# Choose 2 to convert — gdisk converts in memory
# Review the partition table, then:
Command (? for help): w # write GPT to diskBack up your data before doing this. The conversion usually works, but disk operations always carry risk.
Quick Reference Cheatsheet
# --- parted (non-interactive) ---
parted /dev/sdb mklabel gpt
parted /dev/sdb mkpart primary ext4 1MiB 100%
parted /dev/sdb resizepart 1 100%
parted /dev/sdb rm 2
parted -l # list all disks
# --- gdisk (interactive) ---
gdisk /dev/sdb
n = new partition
d = delete partition
p = print table
w = write changes
r = recovery menu
q = quit without saving
# --- fdisk (interactive) ---
fdisk /dev/sdb
o = new MBR table
n = new partition
d = delete partition
t = change type
p = print table
w = write changesOne Last Thing Before You Partition
Always double-check your target disk with lsblk or fdisk -l before running any destructive command. Partition operations work at the block level — there’s no undo. On production systems, I always snapshot the disk or run a quick dd backup of the first few megabytes (where the partition table lives) before making changes:
# Backup the first 10MB (includes MBR + GPT headers)
sudo dd if=/dev/sdb of=~/sdb_header_backup.img bs=1M count=10
# Restore if something goes wrong
sudo dd if=~/sdb_header_backup.img of=/dev/sdb bs=1M count=10With these three tools in your belt and a clear sense of when to use each one, disk partitioning stops being a source of anxiety and becomes just another routine server task.
