September 11, 2026
12 min read
By Kokil Thapa | Last reviewed: September 2026
Disk partitioning and filesystems on Linux are the foundation every production web stack rests on, yet most tutorials stop at a single ext4 root mount. A Laravel app on Ubuntu 24.04, a MySQL 9.7 database, and nightly backup jobs all compete for the same spindle or NVMe if you plan storage late. I've rebuilt servers after a full root partition locked up from logs and uploads. The fix was never "buy a bigger disk first"—it was splitting /var, /home, and data volumes correctly and picking a filesystem that matches the workload. This guide walks through GPT layout, partition tools, filesystem choice, and permanent mounts the way I configure Linux servers for client projects in Nepal and abroad.
Quick answer: Disk partitioning and filesystems on Linux split physical storage into named mount points—typically GPT with
parted or fdisk, ext4 or XFS formatted with mkfs, then mounted via /etc/fstab so data survives reboots.What is disk partitioning on Linux and why does it matter?
A partition is a contiguous slice of a block device exposed as /dev/sda1, /dev/nvme0n1p2, or an LVM logical volume. The filesystem is the structure—directories, inodes, journal—that sits inside that slice. Together they define where your OS, application code, database files, and backups live.
On a typical hosted Ubuntu server, poor layout causes predictable pain. MySQL binlogs fill /var. Laravel storage/logs grows without rotation. A single 40 GB root partition looks fine on launch day and fails six months later. Separating concerns lets you resize, snapshot, or migrate one mount without touching the rest.
Modern servers use GPT, not legacy MBR. GPT supports disks above 2 TB and up to 128 primary partitions. UEFI firmware expects a small EFI System Partition (ESP) formatted as FAT32 at the start of the disk. Skip the ESP on BIOS-only boxes, but most cloud images today ship UEFI-ready.
MBR vs GPT in 2026
MBR survives on old VPS templates and USB installers. GPT is the default on Ubuntu 22.04 and 24.04 cloud images. If you attach a new 500 GB data disk, always initialise it as GPT unless you have a specific legacy constraint.
How do you partition a new disk on Ubuntu Linux?
Identify the raw device before you touch anything. A wrong target wipes production data instantly. Use lsblk -f and sudo fdisk -l to list disks and existing partitions. The boot disk is usually mounted; the new blank disk shows no filesystem and no mountpoint.
On real client EC2 instances—similar to the shared pipeline I run for sites like Notary Kathmandu—I attach a second volume for MySQL data or Laravel storage. The workflow below is the same on bare metal.
Step-by-step with parted and fdisk
- Install tools if missing:
sudo apt update && sudo apt install parted util-linux. - Confirm the device name—assume
/dev/nvme1n1is the new blank disk. - Create a GPT label and one primary partition spanning the disk.
- Format with your chosen filesystem.
- Create a mount point, mount once, then add a permanent
fstabentry.
Using parted for a single data partition:
sudo parted /dev/nvme1n1 --script mklabel gpt
sudo parted /dev/nvme1n1 --script mkpart primary ext4 1MiB 100%
sudo mkfs.ext4 -L laravel_storage /dev/nvme1n1p1
sudo mkdir -p /mnt/storage
sudo mount /dev/nvme1n1p1 /mnt/storage
df -hT /mnt/storagefdisk remains common in tutorials and interviews. Launch it interactively with sudo fdisk /dev/nvme1n1, press g for GPT, n for a new partition, accept defaults, then w to write. Non-interactive scripting often prefers parted or sgdisk.
After partitioning, always run sudo partprobe /dev/nvme1n1 so the kernel rereads the partition table without a reboot. Cloud providers sometimes require a detach-reattach cycle if the table does not appear—rare, but I've seen it on older Xen instances.
Which Linux filesystem should you choose for a web server?
ext4 remains the Ubuntu default and the safe general-purpose choice. XFS excels on large files and high-throughput sequential writes—common for database and media workloads. Btrfs adds snapshots and checksums but adds operational complexity many small teams avoid. For a standard PHP 8.5 + Laravel 13 stack with MySQL 9.7, ext4 on root and XFS on a dedicated data volume is a pattern I use repeatedly.
| Filesystem | Best for | Resize online | Journal | Notes |
|---|---|---|---|---|
| ext4 | Root, /boot, general app files | Yes, with limits | Yes | Default on Ubuntu; mature tooling |
| XFS | MySQL/PostgreSQL data, large uploads | Grow only | Yes | Cannot shrink; plan capacity upfront |
| ext3 | Legacy migrations | Limited | Yes | Avoid on new installs in 2026 |
| Btrfs | Snapshots, subvolumes | Yes | Copy-on-write | More moving parts; test recovery drills |
| swap | Memory overflow buffer | N/A | N/A | Prefer swap file or 2–4 GB partition on small VPS |
Create ext4 with a label for readability:
sudo mkfs.ext4 -L mysql_data /dev/nvme1n1p1
sudo tune2fs -l /dev/nvme1n1p1 | grep "Filesystem volume name"Create XFS for database directories:
sudo mkfs.xfs -L dbdata /dev/nvme1n1p1
sudo xfs_admin -l /dev/nvme1n1p1The official kernel documentation at kernel.org filesystems index remains the authoritative reference when you need feature-level detail. For day-to-day admin work, the Ubuntu mkfs.ext4 man page covers flags you will actually use.
Match mount options to workload. noatime reduces write amplification on busy web roots. Database mounts often use defaults unless your DBA specifies otherwise. Do not enable aggressive tuning you cannot explain during a 2 a.m. outage.
When to use LVM instead of plain partitions
Plain partitions are simpler. LVM flexible disk management on Linux earns its keep when you expect to grow volumes without downtime—adding a disk, extending a logical volume, snapshotting before a MySQL upgrade. Several sister sites on my Deployer 7 pipeline use LVM on EC2 so EBS expansions do not require partition surgery. If the server is a fixed-size VPS you will never resize, skip LVM and keep the stack boring.
How do you mount partitions permanently with /etc/fstab?
A manual mount disappears on reboot. Production servers need persistent mounts declared in /etc/fstab. systemd reads this file at boot and mounts each entry through systemd-fstab-generator, which ties into the same unit machinery described in systemd service management on Linux.
Fetch the UUID—preferred over /dev/sdX names that can shift after reboot or hot-plug:
sudo blkid /dev/nvme1n1p1
UUID=3b8f2c1a-9d4e-4f12-b6a0-xxxxxxxxxxxxAdd a line to /etc/fstab:
UUID=3b8f2c1a-9d4e-4f12-b6a0-xxxxxxxxxxxx /var/lib/mysql xfs defaults,noatime 0 2Validate before rebooting—this step saves careers:
sudo mount -a
sudo systemctl daemon-reload
findmnt /var/lib/mysqlIf mount -a errors, fix fstab immediately. A bad entry can boot the server into emergency mode. Keep a serial console or cloud recovery shell path open on first deploy.
Recommended production mount layout
For a single-disk 80 GB VPS running Laravel and MySQL, a practical split looks like this:
- /boot/efi — 512 MB, vfat, ESP for UEFI.
- /boot — 1 GB ext4, isolated kernels away from a full root.
- / — 25–35 GB ext4, OS, Composer vendor, nginx configs.
- /var — 20–40 GB ext4 or XFS, logs, MySQL if not separated, apt cache.
- swap — 2–4 GB partition or swap file; match RAM for small boxes.
- /home or /srv — optional separate volume for app releases and uploads.
On booking platforms like Adventure Third Pole Trek, user uploads and generated PDFs land in Laravel storage. Moving storage/app to a dedicated mount prevents a marketing PDF batch from freezing SSH when root fills.
What are common disk partitioning mistakes on production Linux servers?
The failures I troubleshoot most often are operational, not exotic kernel bugs. They repeat across Nepal hosting panels and global cloud consoles alike.
One giant root partition
Everything in / feels easy until logs, backups, and temp exports collide. Split /var early. Pair that with log rotation and disk space management so nginx and PHP-FPM logs do not become the incident.
Using /dev/sdX in fstab
Device names reorder. UUIDs and labels stay stable. After cloning a disk or restoring from snapshot, verify blkid output before booting the clone.
Formatting a mounted partition
mkfs on a live root or database mount destroys data. Unmount first, or boot from rescue media. For MySQL, stop the service, sync, unmount, then format.
Ignoring inode exhaustion
ext4 can run out of inodes before bytes. Millions of small cache files trigger this. Check with df -i. XFS handles large file counts differently—another reason to isolate cache directories.
Skipping fsck and backup drills
Filesystem checks matter after unclean shutdown. Schedule automated database backups on Linux to a separate mount or object storage—not the same partition as the live data directory.
When root is already full, read free disk space on Ubuntu for triage commands. Long-term fix is layout, not repeated rm -rf panic.
RAID, encryption, and cloud volumes
Software RAID via mdadm mirrors or stripes block devices—see software RAID on Linux with mdadm when uptime justifies complexity. LUKS encryption protects data at rest on laptops and compliance-sensitive hosts; cloud EBS encryption handles many cases transparently.
On AWS or similar, partition the attached volume inside the guest OS even when the hypervisor presents a single block device. Align with EBS CSI vs Azure Disk CSI if you run Kubernetes; the guest-level rules still apply to node disks.
Permissions after mounting
A fresh mount inherits root ownership. Laravel needs www-data write access on storage and bootstrap/cache. MySQL expects mysql:mysql on its datadir. Apply ownership after mount, not before—otherwise the next mount hides your changes. See Linux file permissions and ACLs explained for the full model.
Key Takeaways
- Use GPT with an EFI partition on UEFI systems; identify disks with
lsblkbefore every destructive command. - Split root,
/var, and application data so logs and uploads cannot brick SSH access. - Prefer ext4 for general web roots and XFS for large database or media volumes—plan XFS size because it cannot shrink.
- Always reference UUIDs in
/etc/fstab, runmount -ato validate, and keep backups on a separate mount. - Consider LVM when you expect online growth; keep plain partitions when simplicity beats flexibility.
- Monitor both space and inodes, rotate logs aggressively, and document your layout for the next engineer.
People Also Ask
What is the difference between a partition and a filesystem on Linux?
A partition is a range of sectors on a disk, defined in the GPT or MBR table and exposed as /dev/nvme0n1p3. A filesystem is the logical structure—ext4, XFS, btrfs—created inside that partition with mkfs. You partition first, format second, mount third.
Should I use ext4 or XFS for Ubuntu in 2026?
Use ext4 for root, boot, and typical Laravel or WordPress 7.1 file trees. Choose XFS for MySQL 9.7 or PostgreSQL 18 data directories handling large sustained writes. Both are production-grade; match the tool to inode count versus throughput.
How big should Linux swap be?
On a 4 GB RAM VPS, 2–4 GB swap partition or swap file is enough for most PHP-FPM workloads. Heavy database servers sometimes run swap at half RAM or disable it entirely for performance—test under your actual peak load before deciding.
Can I repartition a disk without losing data?
Shrinking live partitions is risky without backups. Growing is easier—especially with LVM or cloud volumes that expand at the block layer first. Always take a snapshot or full backup, test on staging, and schedule maintenance windows for production changes.
Plan storage before the disk fills
Disk partitioning and filesystems on Linux are not one-time installer clicks. They are architecture decisions that affect deploys, backups, database growth, and how fast you recover from a bad release. GPT layout, the right mkfs choice, UUID-based fstab entries, and separated mounts cost an extra thirty minutes at provisioning. They save days when /var hits 100% on a Friday evening.
If you are standing up a new Ubuntu server for Laravel, WooCommerce 11.1, or a legal-tech portal, get the storage map right before DNS goes live. For hands-on help with provisioning, monitoring, and ongoing care, see support and maintenance services or testing and optimization when performance tuning follows layout fixes. Useful command references live in best Linux commands for Ubuntu users and Linux performance tuning basics. When you are ready to review a server that already exists, contact us for a storage and filesystem audit.
Frequently Asked Questions
Disk partitioning splits one physical block device into named slices such as /dev/sda1 or /dev/nvme0n1p2, each holding a filesystem with its own capacity. On production Ubuntu servers running Laravel, MySQL, and nightly backups, a single root partition often fails when binlogs, application logs, and uploads compete for space. I've rebuilt servers after a full root locked up from logs alone. Separating /var, application data, and the OS lets you resize, snapshot, or migrate one mount without touching the rest, reducing outage blast radius when one area grows unexpectedly.
A partition is a sector slice exposed as /dev/nvme0n1p2 in the GPT or MBR table. A filesystem is the ext4 or XFS structure inside it, created with mkfs after partitioning.
Use GPT on modern Ubuntu 22.04 and 24.04 cloud images and any disk above 2 TB. GPT supports up to 128 primary partitions and pairs with UEFI firmware expecting a small FAT32 EFI System Partition at the disk start. MBR survives on old VPS templates and USB installers, but when you attach a new 500 GB data volume to an EC2 instance for MySQL or Laravel storage, initialise it as GPT unless a specific legacy constraint forces MBR. On BIOS-only boxes you can skip the ESP, though most cloud images today ship UEFI-ready.
Identify the raw device first with lsblk -f and sudo fdisk -l—a wrong target wipes production data instantly. Install parted and util-linux if missing, confirm the blank disk name, create a GPT label and primary partition with parted or fdisk, format with mkfs.ext4 or mkfs.xfs, create a mount point, mount once, then add a permanent fstab entry using the partition UUID. Run sudo partprobe after writing the table so the kernel rereads it without rebooting. Cloud providers occasionally require a detach-reattach cycle if the table does not appear on older Xen instances.
Use ext4 for root, boot, and typical Laravel or WordPress file trees. Choose XFS for MySQL or PostgreSQL data directories handling large sustained writes.
Plain partitions are simpler and fine for fixed-size VPS instances you will never resize. LVM earns its keep when you expect to grow volumes without downtime—adding a disk, extending a logical volume, or snapshotting before a MySQL upgrade. Several sites on my Deployer 7 pipeline use LVM on EC2 so EBS expansions avoid partition surgery. If the server is a small box with a fixed allocation and your team values boring infrastructure over flexibility, skip LVM. Growing plain cloud volumes is still possible at the block layer, but LVM makes online extension smoother.
Manual mounts disappear on reboot. Fetch the UUID with sudo blkid—preferred over /dev/sdX names that reorder after hot-plug or reboot. Add a line to /etc/fstab such as UUID followed by mount point, filesystem type, and options like defaults,noatime. Validate before rebooting with sudo mount -a, sudo systemctl daemon-reload, and findmnt on the target path. If mount -a errors, fix fstab immediately because a bad entry can boot the server into emergency mode. Keep a serial console or cloud recovery shell available on first deploy.
For a single-disk 80 GB VPS, a practical split includes /boot/efi at 512 MB vfat for UEFI, /boot at 1 GB ext4 for isolated kernels, root at 25–35 GB ext4 for the OS and Composer vendor, /var at 20–40 GB for logs and MySQL if not separated, swap at 2–4 GB, and optionally /home or /srv for app releases and uploads. On booking platforms with user uploads and generated PDFs in Laravel storage, moving storage/app to a dedicated mount prevents a marketing PDF batch from freezing SSH when root fills.
The failures I troubleshoot most often are operational, not exotic kernel bugs. One giant root partition fails when logs, backups, and temp exports collide—split /var early and rotate logs aggressively. Using /dev/sdX in fstab breaks after device reordering; use UUIDs or labels instead. Formatting a mounted partition destroys live data—unmount or boot rescue media first. Ignoring inode exhaustion on ext4 causes df to show free space while millions of small cache files exhaust inodes; check with df -i. Skipping fsck drills and storing backups on the same partition as live data compounds recovery pain.
For a 4 GB RAM VPS, 2–4 GB swap partition or file suffices for most PHP-FPM workloads. Heavy database servers sometimes halve RAM or disable swap entirely.
Shrinking live partitions is risky without backups. Growing is easier, especially with LVM or cloud volumes that expand at the block layer first. Always take a snapshot or full backup, test changes on staging, and schedule a maintenance window for production work. The article treats storage layout as an architecture decision made at provisioning—splitting root, /var, and data volumes upfront costs roughly thirty extra minutes but saves days when /var hits one hundred percent on a Friday evening. Never format a mounted root or database partition; stop MySQL, sync, unmount, then proceed.
Device names like /dev/sda1 reorder after reboot, hot-plug events, or disk cloning. UUIDs and filesystem labels from blkid stay stable across those changes. After restoring from snapshot or cloning a disk, verify blkid output before booting the clone because stale fstab entries referencing old device paths can drop critical mounts or send the server into emergency mode. Labels such as laravel_storage or mysql_data set during mkfs improve readability in fstab while remaining stable, but UUID remains the most common production choice on Ubuntu servers.
noatime reduces write amplification on busy web roots by skipping access-time updates on every read. Database mounts often use defaults unless your DBA specifies otherwise. Do not enable aggressive tuning you cannot explain during a 2 a.m. outage. Match options to workload in fstab alongside the UUID entry—for example defaults,noatime on a MySQL data volume formatted XFS. The article warns against tuning flags you do not understand; boring defaults on database partitions plus noatime on high-traffic application roots is a pattern that balances performance and operability on production PHP stacks.
Software RAID via mdadm mirrors or stripes block devices when uptime justifies the added complexity. LUKS encryption protects data at rest on compliance-sensitive hosts, though cloud EBS encryption handles many cases transparently without guest-level setup. On AWS or similar providers, partition the attached volume inside the guest OS even when the hypervisor presents a single block device—the same GPT, mkfs, and fstab rules apply. Align with your cloud CSI driver if you run Kubernetes, but node-level disk layout still follows standard Linux partitioning workflow regardless of the hypervisor layer.
A fresh mount inherits root ownership, which breaks application writes immediately. Laravel needs www-data write access on storage and bootstrap/cache. MySQL expects mysql:mysql on its datadir. Apply ownership and permissions after mounting, not before—otherwise the next mount hides changes you made on an unmounted path. This step follows every new volume attach workflow: partition, format, mount, chown, then confirm the service starts cleanly. Skipping post-mount permission setup is a common reason newly attached EC2 data volumes appear correctly mounted yet applications throw permission denied errors on first deploy.
0 Comments
Leave a comment
Your email is not published. Comments appear once they have been read. Sign in to have your details filled in.
