Disk Partitioning and Filesystems on Linux

By Khimananda Oli | Last reviewed: August 2026

Disk partitioning and filesystems on Linux form the foundation of every reliable server, yet misconfigurations here cause more data loss and downtime than almost any other layer. Whether you are provisioning a new VPS in Kathmandu or managing a high-throughput database cluster globally, understanding how blocks map to files is non-negotiable. This guide skips the theory and focuses on the exact commands, safety checks, and architectural decisions I use daily as a DevOps engineer to keep storage resilient and performant.

How do you safely perform disk partitioning and filesystems on Linux?

Safe storage management begins before you type a single format command. In production environments, I never touch a disk without first confirming its identity and current state. A common mistake is assuming device names like /dev/sdb are persistent; they can change after reboots or kernel updates. Always identify drives by ID or path using lsblk -f or ls -l /dev/disk/by-id/. For a deeper dive into preparing a fresh server securely, see my guide on initial Ubuntu server setup.

Create GPT partitions with parted

For any modern system, use GPT instead of MBR. GPT supports disks larger than 2 TiB, includes redundant headers, and allows unlimited partitions. The parted tool handles this cleanly:

# Create GPT label
sudo parted /dev/sdb mklabel gpt

# Create primary partition spanning entire disk (aligned)
sudo parted -a opt /dev/sdb mkpart primary 0% 100%

# Verify alignment and layout
sudo parted /dev/sdb print

The -a opt flag ensures optimal I/O alignment based on the disk's topology. Misaligned partitions on SSDs or RAID arrays degrade performance significantly. Always run print afterward to confirm boundaries match expected values.

Abstract with LVM for operational flexibility

I rarely format a raw partition directly in production. Logical Volume Manager (LVM) adds an abstraction layer that enables online resizing, snapshots, and multi-disk aggregation without unmounting. If you later need to extend storage for databases or logs, LVM makes this trivial. For persistent storage patterns in containerized environments, see Kubernetes persistent volumes and storage.

# Initialize physical volume
sudo pvcreate /dev/sdb1

# Create volume group
sudo vgcreate datavg /dev/sdb1

# Create logical volume (use 80% initially to leave room for snapshots/growth)
sudo lvcreate -L 100G -n datalv datavg

# Verify
sudo pvs && sudo vgs && sudo lvs

Leaving free space in the volume group is critical. Snapshots require unallocated extents; running out of VG space during a backup operation can corrupt the snapshot and stall your pipeline.

Which filesystem should you choose: ext4 vs XFS vs Btrfs?

Choosing the right filesystem depends entirely on workload characteristics. There is no universal best option. In my experience across dozens of production systems, ext4 remains the default for good reason, but XFS dominates specific niches. Btrfs has matured but still carries risks for certain enterprise use cases.

For web servers, application containers, and boot volumes, ext4 is the safest choice. It shrinks online, recovers predictably, and every Linux admin knows it. For media servers, video processing, or large sequential writes, XFS performs better under concurrency. Never choose XFS if you anticipate needing to shrink the volume later — it cannot be reduced in size. Btrfs offers compelling features like transparent compression and bit-rot detection, but I reserve it for personal NAS or non-critical archival storage until its RAID5/6 implementation stabilizes further.

How do you format and mount filesystems correctly?

Formatting and mounting seem basic, but production-grade setups require attention to options that affect durability and performance. Default mount options are rarely optimal for servers.

Format with appropriate options

# ext4 with lazy initialization disabled (production-ready immediately)
sudo mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/datavg/datalv

# XFS with reflink enabled (for future dedup/snapshots)
sudo mkfs.xfs -m reflink=1 /dev/datavg/datalv

Lazy initialization speeds up creation but defers inode table zeroing to background I/O, causing unpredictable latency spikes during early writes. Disable it for production volumes. For XFS, enabling reflink at format time is free and unlocks copy-on-write features later.

Persist mounts safely via fstab

Always use UUIDs rather than device paths. Device enumeration order changes; UUIDs do not. After editing /etc/fstab, always run sudo mount -a to validate syntax before rebooting. A malformed fstab entry will drop your server into emergency mode, requiring console access to fix.

# Get UUID
UUID=$(sudo blkid -s UUID -o value /dev/datavg/datalv)

# Example fstab line (ext4)
echo "UUID=$UUID /data ext4 defaults,noatime,errors=remount-ro 0 2" | sudo tee -a /etc/fstab

# Validate without reboot
sudo mount -a && df -hT /data

The noatime option eliminates read-triggered metadata writes, reducing SSD wear and improving throughput for read-heavy workloads. Modern applications rarely need access timestamps; if yours does, use relatime instead.

How do you resize partitions and filesystems without downtime?

Storage requirements grow. Planning for online resizing from day one prevents painful migrations later. This is where LVM pays dividends over raw partitions.

Extend LVM and filesystem online

# Extend logical volume by 50G
sudo lvextend -L +50G /dev/datavg/datalv

# Resize filesystem to fill LV
# ext4:
sudo resize2fs /dev/datavg/datalv
# XFS:
sudo xfs_growfs /data

Note the asymmetry: resize2fs takes the device path, while xfs_growfs takes the mount point. Mixing these up is a frequent source of confusion. Both operations are safe online for growing. Shrinking requires unmounting for XFS (not supported) and careful ordering for ext4 (shrink filesystem first, then LV).

Shrink ext4 safely (offline only)

# Unmount first
sudo umount /data

# Check filesystem integrity
sudo e2fsck -f /dev/datavg/datalv

# Shrink filesystem to 80G
sudo resize2fs /dev/datavg/datalv 80G

# Shrink LV to match
sudo lvreduce -L 80G /dev/datavg/datalv

Never shrink an LVM volume before shrinking the filesystem inside it. Doing so truncates the filesystem metadata and causes irreversible corruption. Always reduce the filesystem first, then the container. For monitoring disk usage trends to anticipate resizing needs, refer to Linux server monitoring with Netdata.

What are common pitfalls and recovery strategies?

Even experienced engineers make mistakes at the storage layer. Knowing failure modes and recovery paths separates competent admins from those who lose data.

• Accidental format on wrong device: Always double-check with lsblk before mkfs. Keep backups of partition tables with sfdisk -d /dev/sda > sda-backup.sfdisk before modifications. Restore with sfdisk /dev/sda < sda-backup.sfdisk.
• LVM metadata corruption: LVM stores metadata copies on each PV. If corrupted, restore from /etc/lvm/archive/ using vgcfgrestore -f archive_file vgname. Regularly back up this directory off-server.
• Filesystem full despite free space: ext4 reserves 5% for root by default. On large data volumes, reduce this with tune2fs -m 1 /dev/datavg/datalv. Also check inode exhaustion with df -i; millions of small files can exhaust inodes before blocks.
• Mount failures after kernel update: Some filesystem modules (like btrfs or xfs) may not load automatically. Add required modules to /etc/modules-load.d/storage.conf to ensure availability at boot.

For teams managing databases on Linux storage, proper partitioning and filesystem tuning directly impacts query performance and replication stability. My guides on MySQL performance tuning and PostgreSQL administration essentials cover storage-specific optimizations in depth.

Practical Next Steps for Production Storage

Disk partitioning and filesystems on Linux demand respect for fundamentals over convenience. Start every deployment with GPT and LVM unless you have a specific reason not to. Choose ext4 for versatility, XFS for scale, and validate every fstab change with mount -a. Document your storage topology in infrastructure-as-code so recovery doesn't depend on tribal knowledge. If your team needs help designing audit-ready, compliant storage architectures or migrating legacy systems safely, reach out to discuss your infrastructure.