The advice everyone repeats without checking it
Every “speed up your Linux install” guide tells you to slap noatime on
every mount in /etc/fstab and call it a day. It’s not wrong exactly,
but it’s not universally the win people treat it as either, and blindly
copying it cost me nothing to try but also gave me nothing to gain on
one of my own filesystems, for a reason worth actually understanding.
noatime vs relatime … check your filesystem first
atime tracking means every single file read also triggers a write to
update the file’s last-accessed timestamp. On a filesystem that
implements this naively, that’s a real write amplification problem …
noatime disables it completely and is a genuine, measurable win.
Except XFS hasn’t behaved that naively since 2006. It defaults to
relatime … only updates atime once a day, or if the file was modified
since the last atime update, whichever comes first. The Arch Wiki puts
it plainly: nobody really needs to bother with noatime on XFS
specifically, because relatime’s default behaviour already captures
essentially all of the benefit.
So on my XFS root and data volumes, I didn’t add noatime at all … I
left the default relatime alone, because there was no measurable win
sitting on the table to grab. Worth checking what filesystem you’re
actually on before copy-pasting noatime everywhere out of habit.
What I did add instead, and why
The two changes that actually did something on XFS specifically:
UUID=xxxx / xfs defaults,logbufs=8,logbsize=256k,inode64 0 0
logbufs=8 and logbsize=256k increase the number and size of the XFS
journal’s log buffers, which reduces how often the filesystem has to
flush its internal journal for mixed read/write traffic … relevant
because this box is a NAS taking Samba/NFS traffic constantly, not
sitting idle between big sequential writes.
inode64 lets XFS allocate inodes across the whole filesystem instead
of restricting them to the first terabyte. Doesn’t matter on a small
drive. Matters the moment you’re planning to grow the volume later, and
costs nothing to set now rather than discover the restriction after
you’ve already filled the first terabyte.
commit … the one I deliberately didn’t touch
commit=N on ext4 (and similar knobs elsewhere) controls how often
dirty data actually gets flushed to disk, in seconds. Raising it from
the default trades a small amount of crash-safety for less disk
activity, since more writes get batched together before an actual sync.
I left this alone everywhere. It’s tempting on a spinning HDD specifically, where fewer, larger writes genuinely reduce mechanical wear and improve throughput. But the actual risk being traded away is real … a longer commit interval means more data sitting in memory, unflushed, at the exact moment of a power loss or crash. For a NAS holding other people’s files, not just my own scratch data, that’s not a trade I want to make quietly by following a generic tuning guide. Default commit interval stays default.
Where SSD and NVMe actually change the calculus
None of the above changes based on drive type … XFS’s journal tuning and
relatime behaviour don’t care whether they’re sitting on spinning rust
or flash. What does change is trim behaviour, and this is the one
place drive type genuinely dictates the right answer:
discard mount option: NOT recommended
XFS’s own documentation is explicit about this … continuous discard
on every delete has a real, measurable performance penalty, and the
recommended approach is a periodic fstrim instead:
sudo systemctl enable --now fstrim.timer
Weekly by default, runs fstrim on every eligible mounted filesystem.
On a spinning HDD this does nothing useful (no trim to speak of) and
costs nothing to leave enabled. On SSD/NVMe it’s the actual right way to
keep write performance from degrading over the drive’s life, without the
per-operation overhead of continuous discard.
nouuid … the option nobody mentions until it bites you
Not in any generic tuning guide, but real enough that it’s worth including here. If a drive ever gets physically moved to a different port or gets a fresh cable, XFS can sometimes flag it as having a “duplicate UUID” and refuse to mount … genuinely the same filesystem, just XFS being cautious about a UUID collision after an unclean disconnect:
UUID=xxxx /mnt/data2 xfs defaults,logbufs=8,logbsize=256k,inode64,nouuid 0 0
nouuid tells XFS to trust it’s the same filesystem rather than
refusing out of caution. Doesn’t matter until the exact moment it does,
and by then it’s an outage, not a tuning exercise.
The actual takeaway
None of this is “here’s the maximally aggressive config, apply everywhere.” It’s closer to: know what your filesystem already handles well by default (XFS + atime), know what genuinely differs by drive type (trim behaviour), and know which knobs trade real safety for a marginal win that isn’t worth it on a box other people’s data lives on (commit interval). The generic advice isn’t wrong, it’s just generic … the actual right config depends on reading what your specific filesystem already does before adding anything on top of it.