Learn Linux Filesystem - Filesystems for Special Workloads

#Introduction

So far we've studied filesystems separately. Episode 10 flips the perspective: you start from the workload, then choose the most suitable filesystem. Databases have different I/O patterns than media file servers; containers have different needs than root filesystems.

A wrong choice isn't always visible as an error — often it shows up as disappointing performance, complicated operations, or data that's hard to protect. By understanding each workload's characteristics, you can make decisions based on data, not habit.

This episode covers four categories: databases, container and VM images, media file servers, and root filesystems. For each category we discuss the main recommendation and its trade-offs.

#Databases: Latency and Consistency

#Database Workload Characteristics

Transactional databases (PostgreSQL, MySQL) have a distinctive pattern: many small operations, frequent fsync, and file sizes that stay stable over their lifetime. What's needed is low latency and predictable crash consistency, not huge throughput.

#Choices for Databases

Two main approaches:

• ext4 or XFS with noatime: predictable, proven, and no surprises from COW mechanisms.
• ZFS with an adjusted recordsize and the ZIL (ZFS Intent Log) on a fast device.

An example of ZFS tuning for databases:

sudo zfs create -o recordsize=8k -o atime=off -o primarycache=all labpool/pgdata

recordsize=8k matches the allocation unit to PostgreSQL's block size. For synchronous write workloads, consider sync=always only if absolute safety is needed — with a performance cost.

For ext4, make sure the data=ordered mode (default) is active and consider a smaller commit so fsync is more responsive:

sudo mount -o noatime,data=ordered /dev/loop0 /mnt/db

A simple rule: if you haven't mastered ZFS tuning, a clean database on ext4/XFS almost always wins on total cost of ownership.

#Containers and VM Images

#Container Image Characteristics

Container and VM images are built in layers — each layer is a delta of the previous one. Copy-on-Write filesystems are the best fit because layers can share blocks without duplication. This is where btrfs and ZFS excel:

• btrfs: Docker's built-in storage driver (btrfs) uses subvolumes and snapshots as image layers.
• ZFS: the zfs driver uses datasets and clones for the same effect, with checksums.

#Snapshots for Images

The pattern used is snapshot as an image template and clone as an instance:

sudo zfs create -V 20G labpool/vm-base
sudo zfs snapshot labpool/vm-base@clean
sudo zfs clone labpool/vm-base@clean labpool/vm-instansi-1

A clone doesn't copy data until it's changed — ten VMs from one template only use a little space above the baseline. This is the main reason ZFS and btrfs dominate modern container and hypervisor storage.

#File Servers and Media

#File Server Characteristics

Media file servers (video, photos, archival backups) are dominated by large files written once and read many times. Transparent compression is very beneficial — text and data media compress well, and storage ratios rise dramatically.

#Choice: ZFS or btrfs with Compression

ZFS with lz4 or zstd is the main choice for media storage:

sudo zfs create -o compression=zstd -o recordsize=1M labpool/media

recordsize=1M is optimal for large sequential files. The btrfs alternative:

sudo mount -o compress=zstd,noatime /dev/loop0 /mnt/media

Both filesystems give you checksums on top of compression — an important quality for long-term archives. For a simple NAS without integrity, ext4 with a noatime mount is also sufficient.

#Root Filesystem and Swap

#Root Filesystem: Stability Above All

The root filesystem must boot reliably, be easy to repair, and not depend on complex mechanisms. Common choices:

• ext4: the safest default — its bootloader, recovery, and documentation are the most mature.
• XFS: the RHEL default; stable for root as long as the partition is created correctly.
• btrfs: used by openSUSE for system-update snapshots; its advantage is fast rollback.

Note btrfs's trade-off on root: system-update snapshots are very useful, but you must be disciplined about managing subvolumes so they don't fill up. For servers without snapshot features, ext4 remains the champion of simplicity.

#Swap and tmpfs

Swap doesn't need a special filesystem — a swap partition is a raw area marked TYPE=swap. For temp data, tmpfs stores everything in RAM:

sudo mount -t tmpfs -o size=1g tmpfs /mnt/ram

tmpfs disappears on reboot — suitable for caches and temporary files, and ideal for very fast read-write workloads that don't need persistence.

#Conclusion

Choosing a filesystem means matching workload characteristics with a filesystem's strengths. Databases need low latency and predictability; containers need COW for image layers; media needs compression and checksums; root needs stability above all.

Key takeaways:

• Databases: ext4/XFS noatime or ZFS with recordsize=8k.
• Containers and VMs: btrfs or ZFS, because COW makes layers and clones efficient.
• Media file servers: ZFS zstd or btrfs compress=zstd.
• Root filesystem: ext4 for simplicity, XFS for RHEL, btrfs if you need snapshots.
• tmpfs stores data in RAM and suits temporary files.
• There's no universal filesystem — workload fit is everything.

In the next episode, episode 11, we cover repair and recovery — from e2fsck, xfs_repair, btrfs check --repair, to zpool scrub and zpool import, plus the basics of data recovery with ddrescue for failing disks. You'll learn what to do when the worst actually happens.