Linux

Ext4 in Linux: Complete Guide to Configuration and Optimization

This guide explains in detail how to configure and optimize the ext4 filesystem in Linux. You will learn to change key parameters, check status, and adapt ext4 for specific tasks, from servers to workstations.

Updated at February 16, 2026
15-30 min
Medium
FixPedia Team
Применимо к:Ubuntu 22.04+Debian 11+CentOS 8+/RHEL 8+Fedora 36+

Introduction / Why This Is Needed

The ext4 filesystem is the de facto standard for most Linux distributions. It offers an excellent balance of reliability, performance, and compatibility. However, "out of the box," ext4 is configured with universal but not always optimal parameters.

This guide will help you deeply tune ext4 for specific tasks: from high-load servers to systems with SSDs or limited disk space. You will learn how to safely change key parameters, check their status, and avoid common mistakes.

Prerequisites / Preparation

Before you begin, ensure that:

  1. You have administrator privileges (sudo).
  2. The e2fsprogs package is installed (usually present by default). To check: dpkg -l e2fsprogs (Debian/Ubuntu) or rpm -qa e2fsprogs (RHEL/CentOS).
  3. You have accurately identified the device (e.g., /dev/sda1). A mistake with the device will lead to data loss!
  4. You have a current backup of important data on the target partition.
  5. You understand that some changes will require remounting or a reboot.

Step 1: Check the Current State of ext4

First, find out what you're working with. Replace /dev/sdX with your device (find it using lsblk or df -h).

# Output all filesystem parameters
sudo tune2fs -l /dev/sdX | less

# Key parameters to watch:
# - Reserved block count: how much space is reserved for root
# - Journal size: size of the journal (usually 128M)
# - Filesystem features: enabled options (e.g., extents, huge_file)
# - Last mount time: when it was last mounted

What to look for:

  • Reserved block count — defaults to 5%. For servers with large disks, this can be a huge amount of "unused" space.
  • Journal size — for SSDs, you can reduce it; for HDDs with intensive writes, you might increase it.
  • Filesystem features — ensure extent, huge_file, dir_nlink are enabled (these are standard for modern kernels).

Step 2: Analyze the Load and Define Goals

Tuning should always be justified. Gather statistics:

# Disk space usage (human-readable)
df -h /mountpoint

# Real-time disk load (press Ctrl+C to exit)
iostat -x 1 5

# SMART disk status (health assessment)
sudo smartctl -a /dev/sdX | grep -E "(SMART|Reallocated|Pending)"

Typical Scenarios and Goals:

  • Server with a large HDD (e.g., 10+ TB): reduce reserved blocks, possibly increase journal.
  • Workstation with an SSD: enable discard (TRIM), reduce journal, disable access time (noatime).
  • System with a small disk (e.g., 32 GB): minimize reservation, use nodiratime.
  • High-load database: adjust commit interval, possibly disable barrier operations (barrier=0), but only if you have a UPS.

Step 3: Change Key Parameters Using tune2fs

Use tune2fs to apply changes. All commands require sudo.

3.1. Changing Reserved Blocks (to save space)

By default, 5% is reserved for root processes. For a 1 TB disk, that's 50 GB! For non-system partitions (data, media), you can reduce this to 1-2%.

# Set 1% reserved blocks
sudo tune2fs -m 1 /dev/sdX

# Set 0% (risky for a system partition!)
sudo tune2fs -m 0 /dev/sdX

3.2. Journal Configuration

  • Reduce journal size (saves space, slightly less reliability after a crash):
    sudo tune2fs -J size=64M /dev/sdX
  • Change journal location (for SSDs, to reduce wear):
    sudo tune2fs -j external:journal_dev /dev/sdX (requires a separate block)

3.3. Enabling/Disabling Options

  • Enable discard (TRIM) for SSDs (recommended):
    sudo tune2fs -o discard /dev/sdX
  • Disable access time writes (faster, saves writes):
    sudo tune2fs -o noatime,nodiratime /dev/sdX
  • Set journal commit interval (in seconds, default is 5):
    sudo tune2fs -o commit=60 /dev/sdX (fewer writes, but higher risk of data loss after a crash)

⚠️ Important: Some options (like discard) can also be specified in /etc/fstab (see Step 6). Changing them via tune2fs makes them permanent for the filesystem itself.

3.4. Changing inode Size

Usually not needed, but if you're creating a filesystem for millions of small files, increase -i (bytes-per-inode). By default, one inode per 16 KB of data.

# Create a new filesystem with one inode per 4 KB (more inodes, more metadata)
sudo mkfs.ext4 -i 4096 /dev/sdX

This parameter can only be set when creating the filesystem.

Step 4: Remount or Reboot

Changes made via tune2fs take effect:

  • For mount options (-o) — after remounting.
  • For internal structures (journal size, reserved blocks) — immediately, but for certainty, reboot or remount.
# If the partition is not root
sudo umount /dev/sdX
sudo mount /dev/sdX /mountpoint

# If it's the root partition (/)
sudo reboot

Verify the partition is mounted with the correct options:

mount | grep /dev/sdX
# Example output: /dev/sda1 on / type ext4 (rw,noatime,discard,data=ordered)

Step 5: Validation and Performance Testing

5.1. Confirm Changes

sudo tune2fs -l /dev/sdX | grep -E "(Reserved block count|Journal size|Mount options)"

5.2. Simple Write Speed Test

# Create a temporary 1 GB file and measure speed
sudo dd if=/dev/zero of=/mountpoint/testfile bs=1M count=1024 oflag=direct

Compare with results from before tuning.

5.3. More Accurate Testing (if bonnie++ is installed)

sudo bonnie++ -d /mountpoint -s 4g -r 2g -u $(id -un)

Pay attention to Sequential Output and Random Seeks.

Step 6: Configure fstab for Permanent Application

If you changed mount options (noatime, discard), they must be in /etc/fstab. Example line:

# Get UUID via: sudo blkid /dev/sdX
UUID=1234-ABCD / ext4 defaults,noatime,discard,errors=remount-ro 0 1

Check fstab correctness:

sudo mount -a
echo $?  # Should be 0

Verifying the Result

  1. The partition is mounted with the correct options (mount | grep mount_point).
  2. tune2fs -l shows the modified Reserved block count and Journal size.
  3. Performance tests (dd, bonnie++) show improvement or stability.
  4. No errors in dmesg | tail or journalctl -xe after reboot.

Potential Issues

Issue: tune2fs: Bad magic number in super-block

Cause: Incorrect device specified or filesystem is not ext4. Solution: Check the device using lsblk -f. Ensure the filesystem type is ext4.

Issue: Device or resource busy during umount

Cause: Partition is in use (e.g., root or has open files). Solution: For root — reboot. For others: sudo fuser -km /mountpoint (careful!) or stop services using the partition.

Issue: I/O errors appear after changing discard

Cause: Old SSDs/disks have poor TRIM support, or discard in fstab conflicts with tune2fs. Solution: Remove discard from fstab, leave it only in tune2fs (or vice versa). For old SSDs, disable discard entirely and use scheduled fstrim via cron.

Issue: System fails to boot after changing parameters

Cause: Incorrect options in fstab or filesystem corruption. Solution: Boot from a live-USB, fix /etc/fstab from another partition, run sudo e2fsck -f /dev/sdX. If tune2fs parameters "broke" the filesystem, revert them using tune2fs with previous values (if you remember them) or restore from a superblock backup (last resort).

F.A.Q.

When should you use ext4 instead of XFS or Btrfs?
Can you safely change ext4 parameters on a running system?
How to check which ext4 parameters are currently active?
What to do if the system doesn't mount after configuring ext4?

Hints

Check current ext4 status
Analyze workload and goals
Adjust key parameters for the task
Remount or reboot the system
Validate changes and check performance
Configure automatic application at boot

Did this article help you solve the problem?

FixPedia

Free encyclopedia for fixing errors. Step-by-step guides for Windows, Linux, macOS and more.

© 2026 FixPedia. All materials are available for free.

Made with for the community