parted Command: Tutorial & Examples

The tool that draws the map a disk follows — partition tables, made readable and safe.

What It Is

parted is how you carve a raw disk into the labelled regions an operating system can actually use. A brand-new drive is just a featureless slab of sectors; before Linux can put a filesystem on it, mount it, and store your files, something has to write a little table at the very front of the disk that says "partition 1 runs from here to here, partition 2 from here to here." That table is the partition table, parted is the GNU tool that edits it, and on any server with more than one disk — or one disk you want to split — this is the command that decides the shape of everything above it.

If you've never partitioned a disk, this is the perfect page to start, because partitioning is one of those topics that sounds terrifying (you are editing the structure of a drive) and is in fact a small, learnable set of ideas. We'll explain every command, every flag, and the two partition-table formats you'll meet — and along the way pick up how disks, sectors, and the boot process actually fit together. One honest warning up front, the kind I wish someone had bolted to my forehead the first time: parted writes changes to disk immediately, the moment you press Enter — there is no "save" step and no undo. Most of this page is the safe, read-only half, and we'll flag every destructive move in red. Read first, cut once.

Danger

Unlike a text editor, parted commits each command to the disk as you type it — rm, mklabel, and mkpart take effect instantly, with no confirmation in script mode and no way back. Run it against the wrong device (/dev/sda when you meant /dev/sdb) and you have just discarded a filesystem. Always confirm the device with lsblk first, and never point a destructive command at a disk that holds data you want.

Your First Look

The safe thing parted does — and the thing you'll actually run most — is print the current layout. Let's look at a real disk. On this machine there's a single 2 TB NVMe SSD, and parted -l lists every block device it can find:

sudo parted -l

Model: Samsung SSD 980 PRO 2TB (nvme)
Disk /dev/nvme0n1: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  1050MB  1049MB  fat32              boot, esp
 2      1050MB  2074MB  1024MB  ext4
 3      2074MB  2000GB  1998GB                     lvm

That's the whole anatomy of a partitioned disk on one screen. The top block is about the disk: its model, total size, sector size, and — crucially — the Partition Table type (gpt here). The table below is one row per partition: where it starts, where it ends, how big it is, what's on it, and any flags. This particular drive is laid out the modern way: a small fat32 EFI boot partition, a /boot partition, and a giant third partition handed over to LVM. You can confirm the shape with lsblk, which shows the same disk from the kernel's point of view:

lsblk

NAME                 SIZE TYPE  MOUNTPOINT
nvme0n1              1.9T disk
├─nvme0n1p1          976M part  /boot/efi
├─nvme0n1p2          977M part  /boot
└─nvme0n1p3          1.9T part

Two tools, same truth. parted reads and writes the table; lsblk only ever reads it. When you just want to see the layout, reach for lsblk — it can't hurt anything. When you need to change it, that's parted.

How I Use It

Here's the exact order of operations in my head whenever a fresh disk shows up — and it's deliberately slow, because this is the one place on a server where a typo is unrecoverable.

First, I find the disk and burn its name into my brain. lsblk shows me every drive and, critically, which ones already have mountpoints. A disk with no partitions and no mountpoints is the new, empty one. A disk with / mounted on it is the one I must never touch. I say the device name out loud — /dev/sdb, /dev/sdb, /dev/sdb — because the entire risk of partitioning is operating on the wrong target.

Second, I print before I cut. sudo parted /dev/sdb print tells me what's already there. An empty disk gives an error or an empty table; a disk with partitions tells me I'd better understand what they are before I overwrite them.

Third, I lay down a label, then partitions. A truly blank disk has no partition table at all, so step one is mklabel gpt — create the table format. Then mkpart for each region. I always use the interactive prompt for real work (it asks me to confirm) rather than the -s script flag, which charges ahead silently.

Fourth — and this is the step almost everyone skips — I check alignment. parted /dev/sdb align-check optimal 1 confirms partition 1 starts on a boundary the SSD likes. Get this wrong and the disk works but runs at a fraction of its speed, silently, forever. More on that below — it's the best secret on this page.

Fifth, only now do I make a filesystem. parted draws the boundaries; it does not (despite the old mkpartfs legacy) put a usable filesystem inside them. That's a separate tool — mkfs — run against the new partition device (/dev/sdb1). People expect parted to format the disk; it doesn't. It builds the plots; mkfs builds the houses.

That sequence — identify, print, label, partition, align-check, mkfs — is the whole job, and the cautious rhythm of it is the point.

GPT vs MBR: The 2 TiB Wall

This is the single most important thing to understand before you partition anything, and it's genuinely fascinating once you see the trap.

There are two partition-table formats you'll meet. The old one is MBR (Master Boot Record), born with the IBM PC in 1983 and called msdos inside parted for historical reasons. The modern one is GPT (GUID Partition Table), part of the UEFI standard that replaced the ancient PC BIOS. The disk above uses GPT — you saw Partition Table: gpt in the print.

Why does it matter which one you pick? Because MBR has a wall built into its very design, and you can walk straight into it without warning. MBR stores each partition's starting sector and length as a 32-bit number. Sit with that for a second, because the whole problem falls out of it. A 32-bit number maxes out at 2³² − 1, which is about 4.29 billion. Multiply that ceiling of sectors by the traditional 512-byte sector size, and you get 2 TiB — and not one byte more. An MBR partition table physically cannot describe a partition, or a disk, larger than 2 TiB. The bits to write down "sector number four-and-a-half billion" do not exist in the format. Try to put MBR on a 4 TB drive and the back half of the disk simply vanishes — there's no number large enough to point at it.

GPT throws that wall away by using 64-bit sector addresses. The new ceiling is so large (2⁶⁴ sectors is roughly 9.4 zettabytes) that it's irrelevant to anything you will ever hold in your hands. GPT also fixes MBR's other quirks for free: MBR allowed only four "primary" partitions (the workaround — an "extended" partition holding "logical" ones — is a kludge you'll still see in old guides), while GPT cheerfully gives you 128. And GPT keeps a backup copy of its own table at the far end of the disk, so a single bad sector at the start doesn't lose your whole layout. MBR keeps exactly one copy, in the first 512 bytes, and if those die, so does the map.

So the rule writes itself: use GPT for everything. The only reason to ever reach for mklabel msdos is a genuinely ancient system that can't boot from GPT, and on a modern Linux server that's essentially never.

Why

The "2 TiB" disks that flooded the market in the early 2010s are exactly where this bites. A surprising number of admins partitioned a 3 TB drive on an old tool, saw "2 TiB," shrugged, and quietly threw away a third of a disk they'd paid for — because the format, not the hardware, couldn't count high enough. The first time you understand the 32-bit ceiling, that mystery evaporates.

Alignment: The Silent Half-Speed Trap

Now the genuine magic — the thing that separates "the disk works" from "the disk works right," and the reason careful people run align-check every single time.

Look back at the very first partition on that real disk. In parted's output it started at 1049kB — an oddly specific number. Drop to sectors and it makes sense:

cat /sys/block/nvme0n1/nvme0n1p1/start

The first partition starts at sector 2048. At 512 bytes per sector, that's exactly 1,048,576 bytes — one full mebibyte — of deliberately wasted space at the front of the disk. Why throw away a megabyte? Because of how the storage underneath actually works, and this is where it gets beautiful.

Your SSD (or a modern "Advanced Format" hard drive) does not really store data in 512-byte chunks, even though it pretends to. Internally it reads and writes in much bigger blocks — typically 4096 bytes, or 4 KiB, the "physical block size." The 512-byte sector is a polite fiction kept alive for backward compatibility; under the hood the drive shuffles 4 KiB pages. Now imagine a partition that starts at sector 63 — which is exactly where the old MBR convention put it, for reasons buried in 1980s disk geometry. Sector 63 is not a multiple of 8 (8 × 512-byte sectors = one 4 KiB physical block), so every single 4 KiB write from the filesystem lands straddling two physical blocks. To change one logical block, the drive must read two physical ones, modify, and write two back. That's the dreaded read-modify-write, and it quietly halves your write throughput — the disk benchmarks at half its spec and nobody can say why, because nothing is broken. It's just misaligned.

The fix is to start every partition on a clean physical-block boundary, and the modern convention — start at 1 MiB (sector 2048) — is a sledgehammer that's always correct: 1 MiB is a multiple of 4 KiB, of 8 KiB, of 64 KiB SSD erase blocks, of basically any alignment any device could possibly want. That megabyte you "waste" at the front buys you full, un-degraded speed for the life of the disk. Cheap at the price.

parted does this for you automatically when you use the default optimal alignment — but you should verify, because a value typed by hand or imported from an old layout can be off:

sudo parted /dev/nvme0n1 align-check optimal 1

1 aligned

1 aligned is the sound of a disk that will run at full speed. If you ever see 1 not aligned, you've found free performance — recreate the partition on a 1 MiB boundary and the read-modify-write penalty disappears. This one check, which takes a second, is the difference between an SSD that flies and one that limps for reasons no metric will ever name out loud.

The Print Output, Explained

Every field in parted print, so you never have to wonder:

Model — what the kernel thinks the drive is (Samsung SSD 980 PRO 2TB (nvme)). The (nvme), (scsi), or (ide) in parentheses is the transport.
Disk /dev/... — the device path and its total size. This is the whole slab.
Sector size (logical/physical) — the two numbers from the alignment story above. 512B/512B is a classic drive; 512B/4096B is "Advanced Format," where the logical fiction (512) differs from the physical truth (4096) — and exactly the case where alignment matters most.
Partition Table — gpt, msdos (MBR), or loop (a whole-device filesystem with no table). This is the single most important line.
Disk Flags — disk-wide flags such as pmbr_boot.
Number — the partition number, the digit you append to the device for the partition's own node (/dev/nvme0n1p**3**, or /dev/sdb**1**).
Start / End — the partition's boundaries, in whatever unit is active. Switch to sectors with unit s to see the raw truth behind round numbers.
Size — End minus Start.
File system — what parted detected sitting inside (fat32, ext4). Blank means it couldn't tell, or there's nothing there — note partition 3 above is blank because it holds LVM, not a plain filesystem.
Name — the GPT partition name (a label, GPT-only; MBR has no such field).
Flags — what the partition is for: boot/esp (an EFI boot partition), lvm, raid, swap, bios_grub (a tiny partition GRUB needs to boot from GPT on legacy BIOS), msftres (a Windows reserved area). These are hints to the OS and firmware, not enforcement.

Reading It by Example

The fast way to build instinct — a layout → what-it-means gallery.

Partition Table: msdos on a 4 TB disk, last partition ending at ~2200GB — you've hit the 2 TiB wall. The disk is bigger than the table can describe; the tail is unreachable. Back up, mklabel gpt, and start over to claim the missing terabytes.

A partition starting at 512B or 32256B (sector 63) — the classic misalignment. align-check optimal will say not aligned. On an SSD this is silently costing you half your write speed. Recreate it at 1 MiB.

Partition Table: loop — there's no partition table at all; the filesystem was written directly to the whole device (common for some virtual disks and USB sticks formatted by GUI tools). Perfectly valid, just unusual — you mount /dev/sdb, not /dev/sdb1.

Error: Can't have a partition outside the disk! — you gave mkpart an end point past the drive's real size. Use 100% as the end and let parted work it out.

Warning: The resulting partition is not properly aligned — parted is telling you, mid-creation, that your hand-typed start sector isn't on a clean boundary. Don't dismiss this; answer Cancel, and let parted pick the start by giving it a % or MiB start instead of a raw sector.

A 1 MiB partition flagged bios_grub at the very front of a GPT disk — not a mistake. On a GPT disk that boots via legacy BIOS (not UEFI), GRUB needs a tiny scratch partition to stash its boot code, because GPT doesn't leave the gap after the MBR that BIOS-GRUB historically used. Leave it alone.

Cheat Sheet

Safe, read-only commands (run these freely):

parted -l — list every disk and its layout (the safe overview)
parted /dev/sdb print — print one disk's table · print free shows the gaps · print all prints everything
parted /dev/sdb unit s print — show start/end in raw sectors (where alignment lives)
parted /dev/sdb align-check optimal 1 — confirm partition 1 is aligned for full speed
parted -j /dev/sdb print — JSON output, for scripts · -m gives terse machine-parseable colon-delimited output

Destructive commands (each writes to disk immediately — be certain of the device):

mklabel gpt — create a fresh GPT table (wipes the existing one)
mkpart primary ext4 1MiB 100% — create a partition; 1MiB start keeps it aligned, 100% fills the disk
rm 2 — delete partition number 2 (instant, no undo)
resizepart 2 200GB — move partition 2's end (does not resize the filesystem inside — a separate step)
name 1 efi · set 1 esp on · toggle 1 boot — set the GPT name and flags

Global flags:

-s / --script — never prompt; for automation. Powerful and unforgiving — it removes the one safety net parted has.
-a optimal / -a minimal / -a none — alignment policy for new partitions (default is sensible; leave it optimal)
-f — auto-answer "fix" to table exceptions in script mode (e.g. a GPT backup in the wrong place)

print partition columns at a glance:

Column	Meaning
Number	Partition number (append to the device, e.g. `/dev/sdb1`)
Start	Where the partition begins
End	Where the partition ends
Size	End minus Start
File system	The filesystem `parted` detected inside (blank if none/unknown)
Name	GPT partition name (GPT only; MBR has no such field)
Flags	What the partition is for (`boot`, `esp`, `lvm`, `raid`, `swap`, `bios_grub`, …)

Gotchas

parted does not make a filesystem. It draws partitions; you still run mkfs (mkfs.ext4 /dev/sdb1) before you can store a single byte. The old mkpartfs is gone for good reasons.
There is no save and no undo. Every command lands on the disk as you type it. The print-first, say-the-name-out-loud ritual exists precisely because of this.
resizepart only moves the boundary, not the data. Grow a partition and the filesystem inside is still its old size until you grow it too (resize2fs, xfs_growfs). Shrink a partition below the filesystem and you've truncated the data — shrink the filesystem first.
The kernel may not notice changes on a busy disk. If a partition is mounted or in use, the kernel keeps the old table cached. partprobe or a reboot re-reads it.
Sizes are binary vs decimal, and parted mixes them. GB means 1,000,000,000 bytes; GiB means 1,073,741,824. When in doubt, use the iB units so what you ask for is what you get.

fdisk, sgdisk, or parted?

parted isn't the only knife in this drawer, and knowing when to grab which is part of the craft.

fdisk is the old hand. For years it spoke only MBR, which made it useless past 2 TiB — but modern fdisk handles GPT too, and many admins now prefer it for one reason: it stages your changes and only writes them when you press w. That single difference — a confirm step parted lacks — makes it noticeably more forgiving for interactive work. If the no-undo nature of parted makes you nervous, fdisk is a friendlier interactive choice.
sgdisk is the scripting specialist — a GPT-only, command-line-driven tool that's the natural pick when automation needs to stamp out identical layouts across a fleet.
parted itself shines for mixed-format work (it speaks GPT, MBR, and a half-dozen exotic labels), for scripted one-liners (parted -s), and for its excellent align-check. It's the Swiss-army option.

There's no wrong choice — they all edit the same table. Pick the one whose safety model matches your nerves.

History & Philosophy

GNU parted arrived in 1999 from Andrew Clausen, and its original killer feature reads quaintly now: it could resize a partition (and the FAT filesystem inside) without destroying the data — the magic that powered a generation of "shrink Windows to dual-boot Linux" tutorials and gave the famous GParted GUI its name (it's parted with a graphical face bolted on). That non-destructive resize was genuinely revolutionary in an era when repartitioning meant backing up, wiping, and restoring an entire disk.

And here's the thread worth pulling. The partition table parted edits has barely changed in forty years. MBR's layout — a 446-byte chunk of boot code, then a 64-byte table of exactly four 16-byte entries, then the two magic bytes 0x55 0xAA that say "yes, this really is a boot sector" — was frozen into the very first IBM PC in 1983 and is still right there in the first 512 bytes of GPT disks today. GPT keeps a fake, "protective" MBR at sector 0 whose only job is to make ancient tools see one big unknown partition and refuse to touch the disk, rather than gleefully "fixing" the GPT they don't understand. So a brand-new 2 TB SSD you partition this afternoon opens, byte for byte, with a 1983 data structure wearing a 2010s one underneath — a fossil deliberately preserved to protect the modern animal that grew over it. Computing is full of these archaeological layers, and the partition table is one of the most perfect: a place where you can run your finger across four decades of compatibility decisions in a single 512-byte sector. Read the Master Boot Record and GUID Partition Table entries on Wikipedia some evening — it's a short, lovely descent into why your disk boots at all.