Mount options and systemd integration · Linux

Mount options affect performance, security, and reliability. Choosing the right options is the difference between a healthy filesystem and a chronic problem.

Performance options

Configuration changeperformance mount options— noatime skips access-time updates (3-5% throughput win) and is filesystem-agnostic. data=ordered is the ext4 default and the safe journalling mode: file data is forced to disk BEFORE its metadata is committed to the journal. Do not reach for data=writeback or barrier=0 to buy throughput - both trade crash correctness for a small win, and barrier=0 no longer even mounts on XFS.

$ mount -o noatime,data=ordered /dev/sda1 /data

Mount options are per-filesystem. noatime and relatime apply everywhere; data= and barrier are ext4 keywords; allocsize= is XFS. Mixing them in one fstab entry produces a mount failure, so keep the two sets straight.

Generic (ext4, XFS, and most others)

Option	Effect	Trade-off
`noatime`	Skip access-time updates	Performance win, breaks atime-based backup and cleanup tools
`relatime`	Update atime only if older than mtime/ctime, or older than 24h	Compromise; the kernel default
`strictatime`	Always update atime	Classic POSIX behaviour, most write amplification

ext4-only

Option	Effect	Trade-off
`data=writeback`	Data may reach disk after its metadata is journalled; ordering is not preserved	Fastest; stale or garbage blocks can appear inside files after a crash
`data=ordered`	Data is forced to disk before its metadata is journalled (the ext4 default)	Slightly slower; no stale-data exposure after a crash
`data=journal`	File data goes through the journal too	Slowest; survives a crash with no data loss window
`barrier`	Enabled by default. Enforces journal-commit ordering through the device write cache	Leave it on. `barrier=0` disables it and makes a volatile write cache unsafe

XFS-only

Option	Effect	Trade-off
`allocsize=64k`	Speculative pre-allocation size hint	Tunes large sequential writes; wrong values waste space
`logbsize=256k`	Larger in-memory log buffer	Fewer log I/Os on metadata-heavy workloads
`inode64`	Allow inodes anywhere in the filesystem	Default since 3.7; only relevant on very old kernels

Never reach for barrier=0

Write barriers are what make a journal trustworthy on a device with a volatile write cache. They force the cache to flush in the right order, so a journal commit is never on disk before the data it describes. barrier=0 removes that ordering. A power loss or hypervisor crash can then replay a journal into a filesystem that is more corrupt than if there had been no journal at all - the exact failure the journal exists to prevent.

It is also not portable. barrier/nobarrier was removed from XFS in kernel v4.19, and man 5 xfs lists it under REMOVED MOUNT OPTIONS: specifying it now yields a mount failure. Put barrier=0 in an XFS fstab line and the next reboot drops the host into emergency.target.

If a vendor benchmark tells you to disable barriers, what they mean is “we assume a non-volatile write cache”. Confirm the controller has a battery or capacitor backup, confirm the cache policy is write-back with a healthy BBU, and document a power-loss test - or leave barriers alone.

Reliability options

Configuration changereliability mount options (ext4 only)— Both options here are ext2/3/4 keywords. errors=remount-ro remounts the filesystem read-only on errors - safer than continuing with a damaged filesystem. data=journal is full data journalling - slowest but safest against power loss. Put either one on an XFS entry and the mount fails.

$ mount -o errors=remount-ro,data=journal /dev/sdb1 /data

Everything in the table below is ext2/3/4 only. XFS has no errors= mount option at all; its error handling is configured after mount, through sysfs.

Option	Effect	When to use
`errors=remount-ro`	Remount read-only on errors	All ext-family production data filesystems
`errors=continue`	Log and continue	Read-only mounts; never on writable data
`errors=panic`	Kernel panic on errors	Embedded/regulated systems
`data=journal`	Full data journalling	Critical data, write-mostly
`data=ordered`	ext4 default; metadata journalled, data flushed before the metadata commit	Most workloads
`data=writeback`	Fastest; data may land after the metadata commit, so a crash can expose stale blocks	Scratch and rebuildable bulk data only

The XFS equivalent

XFS is the RHEL-family default, so on half the fleet none of the above applies. An fstab entry carrying errors=remount-ro on an XFS filesystem does not mount, and the failure surfaces at boot, on the console, with the filesystem missing.

XFS configures error handling per mounted filesystem through sysfs instead, under /sys/fs/xfs/<dev>/error/:

# How many times to retry a failed metadata write before giving
# up and shutting the filesystem down. -1 means retry forever,
# which is the default for some error classes.
cat /sys/fs/xfs/sdb1/error/metadata/EIO/max_retries
cat /sys/fs/xfs/sdb1/error/metadata/EIO/retry_timeout_seconds

# Fail fast instead of retrying forever - the setting that
# matters on unreliable SAN or iSCSI storage, where "retry
# forever" turns a transient path loss into a hung host.
echo 5 | sudo tee /sys/fs/xfs/sdb1/error/metadata/EIO/max_retries

# Whether unmount is allowed to hang waiting for those retries.
# 1 (the default) forces immediate failure at unmount time.
cat /sys/fs/xfs/sdb1/error/fail_at_unmount

These are runtime settings and do not survive a reboot. Apply them from a systemd unit ordered after the mount, or from a tmpfiles rule, if you want them to persist.

Network filesystem options

Configuration changeNFS mount options— mount needs a source and a target: without the server:/export argument it can only look the mount point up in fstab, and fails with 'can't find /srv/nfs in /etc/fstab' when there is no entry. _netdev orders the mount after the network. x-systemd.automount mounts on first access rather than at boot. vers=4.1 pins the protocol version. sec=krb5 uses Kerberos rather than the AUTH_SYS default, which trusts the client's UID claim.

$ mount -t nfs -o _netdev,x-systemd.automount,vers=4.1,sec=krb5 nfs01.example.com:/export/data /srv/nfs

systemd fstab-generator

systemd can mount filesystems without an explicit fstab entry by generating mount units from fstab on the fly. This is useful for complex mounts:

Configuration changesystemd fstab-generator— systemd generates .mount and .automount units from /etc/fstab entries. The unit name is derived from the mount point - /tmp becomes tmp.mount. systemctl cat shows the generated unit. This is how systemd fstab is integrated with the unit dependency system.

$ systemctl cat tmp.mount 2>/dev/null | head -20

_netdev is mandatory for network filesystems

A network filesystem mounted at boot without _netdev is attempted before the network is up, and the boot stalls on it.

The mechanism is systemd’s, not the kernel’s. systemd-fstab-generator turns each fstab line into a .mount unit; _netdev is what makes that unit order itself after network-online.target and pull in remote-fs.target. Without it the mount unit runs early, its job waits, and it fails after DefaultTimeoutStartSec — 90 seconds by default, not the 5-15 minutes an unbounded kernel wait would imply. Check the value on the host rather than assuming:

systemctl show -p DefaultTimeoutStartUSec

What happens after that timeout is decided by nofail:

Without nofail, the mount unit is required by local-fs.target, so its failure fails the target and the boot drops to emergency.target — a console password prompt on a host you probably cannot reach.
With nofail, the failure is tolerated and the boot continues without that filesystem. The service that needs it fails instead, which is a far better failure to have at 3am.

Set the wait explicitly rather than inheriting it:

nfs01:/export/data /srv/data nfs4 _netdev,nofail,x-systemd.device-timeout=30,x-systemd.automount 0 0

x-systemd.device-timeout= is the lever for how long that particular mount waits; it is what turns “the boot hung” into “one mount was late”. Pair it with nofail on every optional mount, and with x-systemd.automount where the filesystem is only needed on first access.

Always add _netdev to the options column for NFS, CIFS, iSCSI and similar mounts.