Planning Large-Capacity Storage: Partitions, Filesystems, and Growth

When you attach a few large disks to your server or physical machine, a quick mkfs tends to cost you six months later: the partition table can't cope, the filesystem doesn't fit the workload, and expanding turns out to be locked in by the original layout. A little planning up front saves a painful migration downtime down the road.

Partition Table: GPT Once You Cross 2TB

The old MBR partition table can only address 2TB — anything beyond that is simply wasted, and you're capped at four primary partitions. For modern disks, always use GPT: it handles huge capacities, imposes practically no limit on partition count, and keeps a backup partition table for resilience.

sudo parted /dev/sdb           # interactive
(parted) mklabel gpt           # create a GPT table
(parted) mkpart data 1MiB 100% # start at 1MiB (keeps alignment)

> Heads-up: mklabel wipes the disk's partition info, and mkfs wipes the data inside a partition. Always confirm the device with lsblk and blkid first — don't mistake your system disk or a disk holding real data for a blank one.

Alignment and inodes

Starting at 1MiB keeps the partition aligned to SSD/RAID physical boundaries, avoiding the write amplification that tanks performance. At format time, if the disk will hold a huge number of tiny files (mail, image thumbnails), use -i to lower the bytes-per-inode ratio and get more inodes; for a handful of large files (video, backups), the defaults are fine — don't waste space.

Filesystem: ext4 or xfs

• ext4: mature and dependable, supports shrinking, the sensible default for small-to-medium, general-purpose volumes.
• xfs: performs better with large files, large capacities, and high concurrency, resizes online but cannot shrink. For TB-scale data disks, databases, or media libraries, reach for it.

sudo mkfs.ext4 /dev/sdb1       # or
sudo mkfs.xfs  /dev/sdb1

Layout: Keep the System Disk and Data Disk Separate

The core principle is to separate the system disk from the data disk. The system disk carries only the OS; the data disk holds your business data on its own. Reinstalling the OS then leaves your data untouched, backups stay clean-grained, and a single-disk failure has a smaller blast radius. Also leave room to grow — when using LVM, don't consume the whole volume group at once; hold some back for future expansion.

Growth: Cloud-Disk Resize or LVM

Two common paths, both sharing one rule: grow the underlying layer first, then the filesystem.

• Cloud-disk resize: after the console enlarges the disk, run growpart /dev/sdb 1 to grow the partition, then grow the filesystem.
• LVM: lvextend -L +500G /dev/vg/data to extend the logical volume, then grow the filesystem.

sudo resize2fs /dev/sdb1       # ext4, online
sudo xfs_growfs /data          # xfs, by mount point

Mount It and Write fstab

A manual mount vanishes on reboot. To make it stick, add an entry to /etc/fstab, and reference the UUID rather than the device name (device names can shift):

sudo mkdir -p /data
sudo blkid /dev/sdb1                       # grab the UUID
echo 'UUID=xxxx /data xfs defaults 0 2' | sudo tee -a /etc/fstab
sudo mount -a                              # validate; a clean run means success

> Never reboot until mount -a runs clean — a bad fstab entry can drop the system into rescue mode.

Summary

Use GPT past 2TB and align at 1MiB; favor xfs for big files and big capacity, pick ext4 when you need to shrink; keep the system and data disks apart and leave headroom; when expanding, remember "underlying layer first, filesystem second"; mount by UUID in fstab and verify with mount -a. Do the planning up front, and growing later is just a few commands.