September 11, 2026
12 min read
By Kokil Thapa | Last reviewed: September 2026
Choosing between Btrfs vs ext4 vs XFS is one of those decisions that looks minor until a disk fills up or a backup fails at 2 a.m. All three ship on modern Linux, but they behave differently under real workloads. On Ubuntu production servers I maintain for Laravel apps, WordPress shops, and legal-tech portals, the filesystem choice affects snapshot strategy, recovery time, and how safely you can grow storage without downtime.
Quick answer: For most Linux web servers in 2026, ext4 remains the safe default; XFS wins on large files and heavy parallel I/O; Btrfs adds built-in snapshots and checksums but needs more planning. Match the filesystem to your backup model, not benchmarks alone.
What is the difference between Btrfs vs ext4 vs XFS?
All three are journaled or copy-on-write filesystems for block storage on Linux. They differ in design age, feature set, and operational maturity. Understanding that design gap matters more than chasing synthetic benchmark scores.
ext4 (fourth extended filesystem) evolved from ext2/ext3. It is the default on many Ubuntu installs. It uses extent-based allocation, journal metadata (or full data journaling optionally), and supports volumes up to 1 exbibyte. It is boring, well understood, and hard to break accidentally.
XFS came from Silicon Graphics and excels at parallel I/O on large files. Red Hat and many enterprise distros default to it for data partitions. XFS uses allocation groups to reduce lock contention. Online grow works well; shrink is not supported in place.
Btrfs (B-tree filesystem) is copy-on-write with built-in checksums, subvolumes, snapshots, compression, and optional RAID profiles at the filesystem layer. It targets flexible storage management but carries a longer list of operational caveats on certain workloads.
| Criterion | ext4 | XFS | Btrfs |
|---|---|---|---|
| Design model | Journaled, extent-based | Journaled, allocation groups | Copy-on-write B-trees |
| Default on Ubuntu Server | Root/data common | Optional, popular for /var | Optional (needs explicit choice) |
| Online grow | Yes | Yes | Yes |
| Online shrink | Limited/risky | No | Yes (with planning) |
| Built-in snapshots | No | No (use LVM) | Yes (subvolumes) |
| Data checksums | No (device may) | No (device may) | Yes |
| Small random writes | Strong | Good | Heavier CoW cost |
| Large sequential I/O | Good | Excellent | Good with tuning |
| Operational maturity | Highest | Very high | Good, workload-dependent |
| Typical web-server pick | Safe default | DB/log heavy hosts | When snapshots justify ops |
The kernel treats all three through the same virtual filesystem layer. Your app sees files and directories. Underneath, write patterns, fsync behaviour, and allocator choices differ. That is why server provisioning playbooks should document the filesystem choice per mount point, not only per server.
Which filesystem should you use for a web server?
Most PHP/Laravel and WordPress stacks on Ubuntu 22.04 or 24.04 run fine on ext4. I have deployed dozens of sites on ext4 root plus ext4 or XFS for /var without filesystem-related incidents. The decision splits by workload shape and how you run backups.
When ext4 is the right call
Pick ext4 when you want the path of least surprise. Shared hosting patterns, modest traffic law-firm portals, WooCommerce shops, and typical custom Laravel applications fit here. ext4 handles many small files reasonably well. Recovery tools and community knowledge are deep.
Typical layout on a single-disk VPS:
/— ext4, 20–40 GB, OS and application code/var— ext4 or XFS, logs, MySQL/PostgreSQL data, uploads- Separate backup target — object storage or another server, not same-disk snapshots alone
When XFS earns its place
Choose XFS when the server stores large media libraries, heavy log volume, or database files that grow big and fast. On booking systems and eCommerce platforms with substantial product images, XFS on a dedicated data mount often scales more smoothly. XFS performs well when many threads write concurrently.
Important constraint: you cannot shrink an XFS filesystem in place. Plan partition sizes up front. Growing online is straightforward:
sudo xfs_growfs /var/lib/mysql
For ext4 growth after expanding the underlying volume:
sudo resize2fs /dev/vg0/data
When Btrfs makes sense
Btrfs shines when you want cheap local snapshots before deployments or package upgrades. On sister sites I maintain with Deployer 7 and GitLab CI, a pre-deploy snapshot can shorten rollback time when opcache or permissions go wrong. Btrfs is not a substitute for off-site backups though.
Enable compression for read-heavy static assets if CPU headroom exists:
sudo mount -o compress=zstd:3 /dev/sdb1 /srv/backups
Avoid Btrfs for database data directories unless you understand CoW overhead and disable copy-on-write on those paths:
sudo chattr +C /var/lib/mysql
The +C flag sets the NOCOW attribute before files are created. Applying it after data exists requires migration.
How do you benchmark Btrfs vs ext4 vs XFS before choosing?
Do not pick a filesystem from a single blog benchmark. Test your actual workload on staging hardware that matches production. A Nepal VPS with 2 vCPU and NVMe behaves differently from a bare-metal RAID10 box.
Tools that produce useful signal
- fio — synthetic I/O with configurable block sizes and fsync patterns. Mimic database and upload behaviour.
- ioping — quick latency check for random small writes. Relevant for heavy session or cache files.
- Real app smoke test — import a MySQL dump, run Laravel migrations, warm opcache, then measure deploy time.
- Disk space drill — fill
/varto 90% and observe behaviour. Some filesystems degrade gracefully; others stall hard.
Example fio job simulating mixed web workload:
fio --name=webmix --directory=/mnt/test --rw=randrw --rwmixread=70 \
--bs=4k --size=2G --numjobs=4 --iodepth=32 --runtime=120 --group_reporting
Run the same job on each candidate filesystem after a clean mkfs. Record IOPS, latency p99, and CPU usage. Btrfs often shows higher CPU on small random writes due to checksums and CoW. XFS frequently leads on large sequential throughput. ext4 sits in the middle for mixed small-file work.
Interpreting results for PHP stacks
Laravel and WordPress spend significant time in the database, not raw filesystem throughput. MySQL 9.7 or PostgreSQL 18 on a properly sized innodb_buffer_pool or shared_buffers cache reduces disk pressure. Filesystem choice matters most for logs, uploads, backup windows, and full-table scans.
On production booking platforms with Livewire and frequent writes, I watch fsync latency more than peak MB/s. A filesystem that spikes latency under fsync load hurts checkout flows more than a lower sequential score.
Use the JSON formatter to inspect benchmark output exported from monitoring agents if you pipe results into JSON logs. Consistent formatting speeds comparison across test runs.
How do snapshots and backups differ across Btrfs vs ext4 vs XFS?
Backups and snapshots solve different problems. Snapshots are fast, local, and point-in-time. Backups are off-site and survive fire, theft, ransomware, and operator error. Your filesystem choice affects snapshot ergonomics, not backup replacement.
ext4 and XFS snapshot options
Neither ext4 nor XFS provides native per-directory snapshots. You typically use LVM thin snapshots, hardware RAID snapshots, or hypervisor-level snapshots on cloud VPS platforms. LVM snapshots on ext4/XFS are proven but need free space in the volume group. Long-lived snapshots hurt write performance as copy-on-write accumulates.
sudo lvcreate -L 10G -s -n www_snap /vg0/www_data
Btrfs native snapshots
Btrfs snapshots are subvolume-level and cheap at creation time. They fit pre-deploy hooks:
sudo btrfs subvolume snapshot / /snapshots/pre-deploy-$(date +%F-%H%M)
Send/receive supports incremental off-site replication to another Btrfs volume:
sudo btrfs send -p /snapshots/base /snapshots/incr1 | ssh backuphost btrfs receive /backups/host1
Schedule btrfs scrub monthly on production arrays to verify checksums. Scrub reads every block and repairs from RAID mirrors when possible. Document scrub windows in your maintenance runbook.
For server migrations, filesystem choice affects dump-and-restore time. XFS-to-XFS block copy via rsync or LVM move is routine. Converting ext4 to Btrfs in place is possible with btrfs-convert but plan a maintenance window and verify boot loader support.
When should you avoid Btrfs on production Linux servers?
Btrfs is production-ready for many workloads on current kernels. Still, certain patterns cause pain. I treat Btrfs as a deliberate opt-in, not the default for client VPS instances unless snapshots are a stated requirement.
Workloads that fight Btrfs
- Database directories without NOCOW — MySQL, PostgreSQL, and Redis AOF files on CoW paths can fragment and slow down under sustained random writes.
- Very small VPS disks — Btrfs metadata overhead and the need for free space for balance operations hurt on 20 GB root volumes.
- Nested RAID5/6 Btrfs profiles — write hole issues historically plagued RAID5/6; mirror or RAID10 at hardware level is safer for critical data.
- Heavy swap on Btrfs — disable CoW on swap files or use a dedicated swap partition formatted ext4.
- Teams without scrub/monitor discipline — checksums help only if you act on scrub results and monitor
btrfs device stats.
Check filesystem health regularly:
sudo btrfs filesystem show
sudo btrfs device stats /
sudo dmesg | grep -i btrfs
ext4 and XFS also need monitoring. Run e2fsck after unclean shutdown. Watch XFS for XFS error messages in dmesg after power loss. No filesystem removes the need for disk and inode alerting.
Cloud and hosting realities in Nepal
Many Nepal businesses run on budget VPS plans from local or regional providers. Disks are often single NVMe without hardware RAID. In that world, ext4 or XFS plus automated off-site backups beats exotic filesystem features. Rs 1,500–3,000/month (~USD 11–22) VPS tiers rarely include snapshot APIs; you build your own with restic or Borg.
When clients ask about hosting and domain setup, I document mount layout in the handover notes. The next developer should know whether /var/www shares root or lives on a separate volume and which filesystem backs it.
Kernel and distro alignment
Ubuntu 24.04 LTS and current RHEL-family releases ship mature XFS and Btrfs tooling. Always match documentation to your kernel line. The official kernel documentation at docs.kernel.org filesystem index is the authoritative feature reference. For Btrfs administration detail, the wiki at btrfs.readthedocs.io covers subvolumes, balance, and device management. Red Hat documents XFS capacity and repair at Red Hat file system overview.
After a web stack migration, revalidate mount options. noatime remains a sensible default on all three filesystems for web roots. Avoid aggressive tuning until metrics justify it.
Key Takeaways
- Default to ext4 for general-purpose Ubuntu web servers unless metrics or features push you elsewhere.
- Put large MySQL data, media stores, and heavy log volumes on XFS when you can size partitions without needing shrink.
- Choose Btrfs when local snapshots and checksums justify extra operational overhead and you will run scrubs.
- Benchmark with fio and real app tests; fsync latency often matters more than peak throughput for PHP stacks.
- Never treat filesystem snapshots as backups—schedule off-site copies regardless of Btrfs vs ext4 vs XFS.
- Document mount layout and filesystem type in provisioning docs so migrations and disaster recovery stay predictable.
People Also Ask
Is Btrfs stable enough for production in 2026?
Yes, for many Linux server workloads on current kernels and when you follow documented best practices. Facebook and several distros use Btrfs at scale. Still, teams that will not run scrubs or configure NOCOW on database paths should prefer ext4 or XFS for lower operational risk.
Is XFS faster than ext4?
XFS often leads on large-file sequential I/O and highly parallel writes. ext4 frequently matches or wins on small random file workloads typical of PHP codebases and WordPress installs. The gap narrows on SSD and NVMe hardware with adequate RAM for caching.
Can you convert ext4 to Btrfs without losing data?
The btrfs-convert utility can convert ext4 in place on unmounted or carefully prepared volumes. Always take a full backup first. Boot loader and snapshot layout need review after conversion. For production, a clean mkfs plus rsync migration is usually cleaner.
Which filesystem does Ubuntu Server use by default?
Ubuntu Server installs ext4 on the root filesystem by default. You can choose manual partitioning and select XFS or Btrfs during install. Cloud images from major providers may differ; check with findmnt -no FSTYPE / on first login.
Pick the filesystem your ops team can support
The honest summary for Btrfs vs ext4 vs XFS on web servers: ext4 is the default because it is predictable. XFS is the performance choice for big data mounts. Btrfs is the feature-rich option when snapshots and checksums match your runbook. None of them replace backups, monitoring, or correct mount sizing.
If you are provisioning a new server, migrating hosts, or unsure whether your current disk layout will survive the next deploy, I can review your stack and recommend a layout that fits Laravel, WordPress, or custom app workloads. See Linux system administration services, browse the portfolio for production examples, or contact us to discuss your hosting setup.
Frequently Asked Questions
All three are Linux block filesystems above the VFS layer, but they differ in design. ext4 is journaled and extent-based—the predictable default on many Ubuntu installs. XFS uses allocation groups and excels at parallel I/O on large files. Btrfs is copy-on-write with built-in checksums, subvolumes, snapshots, and optional compression. ext4 has the highest operational maturity; XFS suits heavy data mounts; Btrfs trades extra planning for snapshot and checksum features.
For most PHP, Laravel, and WordPress stacks on Ubuntu 22.04 or 24.04, ext4 remains the safe default. Pick XFS when the server holds large media libraries, heavy logs, or fast-growing database files on a dedicated mount you can size without needing shrink. Choose Btrfs when cheap local snapshots before deployments justify the ops overhead. Match the choice to your backup model and workload shape, not synthetic benchmarks alone.
Yes, for many workloads on current kernels when you follow documented practices. Facebook and several distros use it at scale. Teams that will not run scrubs, monitor device stats, or set NOCOW on database paths should prefer ext4 or XFS for lower operational risk.
XFS often leads on large sequential I/O and highly parallel writes. ext4 frequently matches or wins on small random workloads typical of PHP codebases and WordPress installs. The gap narrows on SSD and NVMe with adequate RAM for database caching.
Ubuntu Server formats the root filesystem as ext4 by default. You can select XFS or Btrfs during manual partitioning at install. Cloud images may differ—run findmnt -no FSTYPE / on first login to confirm.
The btrfs-convert utility can convert ext4 in place on unmounted or carefully prepared volumes. Always take a full backup first, and review boot loader and snapshot layout after conversion. For production servers, a clean mkfs followed by rsync migration is usually cleaner and less risky than in-place conversion during a live maintenance window.
No. XFS does not support in-place shrink. Plan partition sizes up front when choosing XFS for a data mount. Online grow is straightforward with xfs_growfs after expanding the underlying volume. ext4 online shrink is limited and risky; Btrfs can shrink with planning. This constraint alone pushes many web-server layouts toward ext4 on root or careful upfront sizing for XFS data partitions.
Snapshots are fast, local, point-in-time copies; backups are off-site and survive hardware loss, ransomware, and operator error. Neither ext4 nor XFS offers native per-directory snapshots—you use LVM thin snapshots, hardware RAID, or hypervisor snapshots instead. Btrfs creates cheap subvolume-level snapshots and supports send/receive for incremental replication. Every production web server still needs off-site backups regardless of filesystem; snapshots alone are not a backup strategy.
Avoid Btrfs as a default when database directories run without NOCOW on MySQL, PostgreSQL, or Redis AOF paths, when disks are very small VPS volumes where metadata overhead hurts, when you rely on nested Btrfs RAID5/6 profiles, when swap files sit on CoW paths without tuning, or when the team will not run monthly scrubs and monitor btrfs device stats. ext4 or XFS plus automated off-site backups is safer for budget single-disk hosting.
Test your actual workload on staging hardware matching production—not a single blog benchmark. Use fio with mixed random read/write jobs mimicking web I/O, ioping for small-write latency, and a real app smoke test importing a MySQL dump and running Laravel migrations. Fill disk to ninety percent and watch behaviour. Record IOPS, p99 latency, and CPU usage. For PHP stacks, fsync latency under load often matters more than peak sequential throughput because most time sits in the database cache.
A proven pattern from the article: ext4 on root at twenty to forty gigabytes for OS and application code, ext4 or XFS on /var for logs, MySQL or PostgreSQL data, and uploads, and a separate backup target on object storage or another server—not same-disk snapshots alone. Document whether /var/www shares root or lives on a separate volume. Budget Nepal VPS tiers around Rs 1,500–3,000 per month rarely include snapshot APIs, so plan restic or Borg off-site copies.
MySQL, PostgreSQL, and Redis AOF files on default CoW Btrfs paths can fragment and slow under sustained random writes. Set the NOCOW attribute with chattr +C on the directory before files are created. Applying it after data exists requires migration. Btrfs is not wrong for servers overall, but database data directories need explicit CoW handling or teams should use ext4 or XFS for those mounts instead.
Both support online grow after expanding the underlying block device or LVM volume. For XFS, run xfs_growfs on the mount point—for example on /var/lib/mysql after the disk is enlarged. For ext4, run resize2fs on the device such as /dev/vg0/data after the volume group or partition grows. XFS grow is routine; remember XFS cannot shrink afterward, so size partitions with future growth in mind rather than over-allocating reversible space.
No. Snapshots are fast and local; they do not survive disk failure, theft, ransomware, or accidental deletion of the whole volume. Btrfs checksums and snapshots help rollback and detect bit rot when you scrub, but you still schedule off-site copies with tools like restic or Borg. On ext4 and XFS, LVM snapshots are useful for pre-deploy rollback but need free volume-group space and hurt write performance if kept too long. Treat snapshots as a complement to backups, never a substitute.
noatime remains a sensible default on web roots for ext4, XFS, and Btrfs because it reduces unnecessary write traffic on read-heavy PHP and static asset workloads. Avoid aggressive tuning until metrics justify it. Revalidate mount options after stack migrations. Monitor all three: run e2fsck after unclean shutdown on ext4, watch dmesg for XFS errors after power loss, and schedule monthly btrfs scrub on Btrfs arrays. Set disk and inode alerting regardless of filesystem choice.
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.
