ZFS atime: The Tiny Toggle That Can Fix ‘Slow Writes’

Every storage engineer eventually meets the case of “slow writes” where the graphs look wrong, the disks look bored, and the application teams swear they didn’t change anything. Then you notice the workload: millions of tiny files, read-heavy, on a dataset with atime=on. You flip one property and suddenly the write path clears its throat and starts behaving like a grown-up.

This is that story—minus the fairy tale ending where one knob fixes everything forever. ZFS access time updates (atime) can be a real performance tax in the wrong place, and they’re subtle because they don’t look like “writes” to most people. They look like “reads.” But the filesystem is quietly doing extra metadata work on your behalf, and that work has to land somewhere: in the intent log, in TXGs, in the I/O scheduler, and often in the latency your app swears is “network.”

What atime really is (and why it exists)

atime is the file “access time”: a timestamp updated when a file is read. Not modified—read. Historically, that sounded useful: mail systems looking for “new mail,” backup tools deciding what was touched, cleanup scripts deleting “unused” content, security tooling building timelines, and admins answering the eternal question, “Is anyone using this?”

On Unix-like filesystems, atime is one of the classic trio:

• mtime: when file contents changed
• ctime: when metadata changed (permissions, owner, link count, etc.)
• atime: when file was last accessed (read)

In ZFS, atime is a dataset property, so you can enable/disable it per dataset without remount gymnastics. That’s good design: different directories can have different truth. Your mail spool can keep atime. Your container image cache probably shouldn’t.

But here’s the twist: atime isn’t “free metadata.” Updating it requires writing metadata back to disk eventually. With copy-on-write semantics, metadata updates are real allocations, real dirty blocks, and real work for the transaction groups (TXGs). ZFS is excellent at being correct; it’s not obligated to be cheap about it.

Joke #1 (storage-approved): atime is like a receptionist who writes down every visitor’s name—useful until they start doing it during a fire drill.

How atime turns reads into writes (and why that can stall real writes)

When you read a file on a dataset with atime=on, ZFS updates the inode-like metadata (ZFS uses objects, dnodes, and metadata blocks rather than classic inodes, but the point stands). That update marks metadata dirty in RAM. Dirty data must be committed during the next TXG sync. If you’re reading millions of files, you’re generating a steady stream of metadata writes.

“So what? It’s metadata; it’s small.” That’s the common assumption, and it’s wrong in exactly the workloads that make people angry:

• Small-file scans (antivirus, backup enumerations, CI caches, monorepo checkouts, container registry layers, image caches)
• Directory-walk heavy apps (language package managers, static site generators, build systems)
• NFS/SMB shares where clients do lots of metadata reads
• VM or container hosts with lots of tiny reads across many datasets

The write load isn’t just “some bytes.” It’s a chain of costs:

1) Dirty metadata competes with real writes

TXGs have finite time and resources. If you have constant background metadata churn, your actual application writes can get stuck behind it. Latency grows; throughput becomes spiky.

2) Copy-on-write amplifies metadata work

ZFS doesn’t overwrite blocks in place; it writes new blocks and updates pointers. Updating atime can cascade into indirect block updates and metadata tree changes. The amount of I/O per “tiny” metadata update can exceed your intuition, especially with fragmentation and small blocks.

3) Sync behavior can make it worse

If your workload is sync-heavy (databases, NFS with certain export options, applications calling fsync() frequently), the ZIL/SLOG path is sensitive to extra metadata writes. atime updates don’t always behave like sync writes, but they can contribute to the overall dirty set and pressure the pipeline at the worst moment.

4) ARC pressure and eviction side effects

Metadata lives in the ARC too. A metadata-heavy scan with atime enabled can inflate metadata churn, pushing out useful cached data and causing more real disk reads. That’s how you get the special kind of incident where “reads made writes slower, and then reads got slower too.”

5) It hides behind “read workload” labels

Teams look at the app and say “it’s read-only,” then wonder why the pool shows writes. atime is one of the classic reasons. Another is snapdir=visible and users wandering into .zfs/snapshot, but that’s a different article.

Facts & history: the small timestamp with a long tail

Some context makes it easier to choose the right behavior instead of cargo-culting atime=off everywhere.

1. atime predates ZFS by decades. It comes from early Unix filesystem semantics where timestamps were cheap compared to human time spent debugging.
2. Linux’s “relatime” became popular because strict atime was too expensive. The industry basically admitted “updating atime on every read is too much” and introduced a compromise.
3. NFS and mail spools historically relied on atime. Some old tooling used atime to decide whether a mailbox was “newly accessed” or safe to modify.
4. Flash changed the pain profile. SSDs can handle random reads well, but metadata writes still cost latency and can trigger write amplification and garbage collection at inconvenient times.
5. ZFS was designed for correctness and observability. The whole “you can see what ZFS is doing” ethos is why properties like atime are visible and controllable per dataset.
6. OpenZFS made feature growth a first-class concern. That’s why you’ll see different defaults across platforms and eras: not everyone shipped the same tuning philosophy.
7. Some backup tools used atime as a poor man’s telemetry. “If it was accessed, it must be important” is not a great policy, but it existed.
8. atime interacts with human behavior. Running find across a tree on an atime-enabled dataset can turn a harmless audit into a metadata write storm. Congratulations: your read-only compliance scan just became a write workload.
9. atime is one of the few performance toggles that is also a policy decision. Disabling it is not only faster; it changes what truth your system records about usage.

When disabling atime is the right move (and when it isn’t)

Disabling atime is often the correct default for modern performance-sensitive datasets, but “often” is not “always.” The right decision depends on whether you need access-time semantics for actual behavior or compliance, not vibes.

Disable atime for these common cases

• Build caches (CI workspaces, artifact caches, language package caches)
• Container storage (image layers, overlay backing stores, registry caches)
• Web static assets (served by processes that already have logs)
• VM images (atime inside the guest is what matters, not on the host’s dataset)
• Home directories in corporate environments where atime isn’t used for quotas/cleanup

Think twice before disabling atime here

• Mail spools or legacy tooling that checks atime (less common now, but not extinct)
• Forensic or compliance workflows where “was accessed” is meaningful evidence
• Data lifecycle automation that uses atime to expire “unused” files (also questionable design, but real)

What about “relatime” on ZFS?

On Linux, mount options like relatime are widely understood for ext4/xfs. On ZFS, behavior is driven primarily by ZFS properties and the ZPL layer; depending on platform and implementation, you may see mount options reflected, but you should treat ZFS properties as the source of truth. Practically: if you want predictable behavior, set atime at the dataset level and verify it with zfs get.

Joke #2: “We’ll just enable atime for auditing,” said the team, shortly before auditing the storage performance incident they created.

Fast diagnosis playbook: what to check first, second, third

This is the playbook I use when someone pings “ZFS writes are slow” and the clock is running. The goal is to identify whether atime is a likely contributor within 10–15 minutes, not to produce a thesis.

First: confirm the symptom and classify the stall

1. Is it latency or throughput? “Slow writes” might mean high commit latency (sync) or low sequential throughput (async). Use pool and vdev stats to decide.
2. Is the pool busy? If the pool is not busy but the app is slow, look at sync settings, ZIL/SLOG, and CPU contention.
3. Is the workload actually read-heavy? If yes, atime becomes suspicious.

Second: look for metadata churn signatures

1. High IOPS with low bandwidth on the pool: classic small-block/metadata workload.
2. Lots of “writes” during a read scan: could be atime updates.
3. TXG sync time increases or commits become bursty: metadata dirtiness can push you there.

Third: check the dataset properties and validate the hypothesis

1. Is atime=on? Verify on the dataset that hosts the workload, not just the pool root.
2. Can you reproduce with a controlled read scan? A quick find or tar read can show if reads trigger writes.
3. Can you safely toggle atime off for a test? If policy allows, change it and measure again.

Practical tasks: commands, outputs, and what they mean

These are hands-on tasks you can run in production with minimal risk. The goal isn’t just “run command,” but “interpret signal.” Replace pool/dataset names as needed.

Task 1: Identify the dataset behind a path

cr0x@server:~$ df -T /srv/buildcache
Filesystem           Type 1K-blocks     Used Available Use% Mounted on
tank/buildcache      zfs  500000000 12000000 488000000   3% /srv/buildcache

Interpretation: The dataset is tank/buildcache. That is where you check atime—not tank, not “whatever the pool default was years ago.”

Task 2: Check atime and other relevant dataset properties

cr0x@server:~$ zfs get -o name,property,value,source atime,recordsize,primarycache,logbias,sync tank/buildcache
NAME            PROPERTY      VALUE   SOURCE
tank/buildcache atime         on      local
tank/buildcache recordsize    128K    inherited
tank/buildcache primarycache  all     default
tank/buildcache logbias       latency default
tank/buildcache sync          standard default

Interpretation: atime=on is explicitly set (local). This is a candidate for “reads causing metadata writes.” Also note recordsize and caching—useful later, but don’t change five knobs at once.

Task 3: Observe pool I/O at a glance

cr0x@server:~$ zpool iostat -v tank 1
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        120G   1.70T  15000   9000   180M   40M
  mirror    60G    850G    8000   4500    90M   20M
    nvme0n1    -      -    4000   2200    45M   10M
    nvme1n1    -      -    4000   2300    45M   10M
  mirror    60G    850G    7000   4500    90M   20M
    nvme2n1    -      -    3500   2200    45M   10M
    nvme3n1    -      -    3500   2300    45M   10M

Interpretation: High read ops, non-trivial write ops, moderate bandwidth. If the app believes it’s “just reading,” those 9k write IOPS are a clue. atime is a common reason; not the only one.

Task 4: Verify mount options and ZFS view (sanity check)

cr0x@server:~$ mount | grep '/srv/buildcache'
tank/buildcache on /srv/buildcache type zfs (rw,xattr,noacl)

Interpretation: Don’t expect to see atime here on ZFS like you would on ext4. Use zfs get as your truth.

Task 5: Prove reads are generating writes (controlled scan)

cr0x@server:~$ sudo sh -c 'zpool iostat -v tank 1 & sleep 2; find /srv/buildcache -type f -maxdepth 3 -print0 | xargs -0 -n 200 head -c 1 >/dev/null; sleep 2; pkill -f "zpool iostat -v tank 1"'
# (iostat output scrolls; look for a write spike during the read scan)

Interpretation: If a read-only head scan produces sustained writes, atime is likely in play. This isn’t a perfect experiment, but it’s a fast one.

Task 6: Check file atime before and after a read

cr0x@server:~$ FILE=/srv/buildcache/example.bin
cr0x@server:~$ stat -c 'atime=%x mtime=%y ctime=%z %n' "$FILE"
atime=2025-12-24 09:41:02.000000000 +0000 mtime=2025-12-20 11:10:09.000000000 +0000 ctime=2025-12-20 11:10:09.000000000 +0000 /srv/buildcache/example.bin
cr0x@server:~$ dd if="$FILE" of=/dev/null bs=128K count=1 status=none
cr0x@server:~$ stat -c 'atime=%x mtime=%y ctime=%z %n' "$FILE"
atime=2025-12-24 10:02:18.000000000 +0000 mtime=2025-12-20 11:10:09.000000000 +0000 ctime=2025-12-20 11:10:09.000000000 +0000 /srv/buildcache/example.bin

Interpretation: atime changed on read. That implies metadata updates. The real question is whether that metadata churn is large enough to hurt you. In small-file workloads, it often is.

Task 7: Disable atime on a dataset (safe, immediate, reversible)

cr0x@server:~$ sudo zfs set atime=off tank/buildcache
cr0x@server:~$ zfs get -o name,property,value,source atime tank/buildcache
NAME            PROPERTY  VALUE  SOURCE
tank/buildcache atime     off    local

Interpretation: This changes behavior going forward. It does not “rewrite” existing metadata history; it stops future updates. If you need a test window, you can flip it back.

Task 8: Measure the difference (before/after) with the same read scan

cr0x@server:~$ sudo sh -c 'zpool iostat -v tank 1 & sleep 2; find /srv/buildcache -type f -maxdepth 3 -print0 | xargs -0 -n 200 head -c 1 >/dev/null; sleep 2; pkill -f "zpool iostat -v tank 1"'
# Compare write IOPS now versus earlier

Interpretation: If writes drop dramatically during reads, you’ve found a real contributor to the slow-write story. If not, atime wasn’t your villain—or wasn’t your only villain.

Task 9: Confirm whether sync writes are the actual bottleneck

cr0x@server:~$ zfs get -o name,property,value,source sync,logbias tank/buildcache
NAME            PROPERTY  VALUE     SOURCE
tank/buildcache sync      standard  default
tank/buildcache logbias   latency   default

Interpretation: If the app is slow only on fsync-heavy operations, atime changes might not move the needle much. But atime can still add background noise that worsens latency variance.

Task 10: Watch ZFS latency distribution at the device layer

cr0x@server:~$ iostat -x 1
Linux 6.8.0 (server)  12/24/2025  _x86_64_  (32 CPU)

Device            r/s     w/s   rkB/s   wkB/s  aqu-sz  await  r_await  w_await  svctm  %util
nvme0n1         3800    2100  48000   11000     2.1    0.5     0.4      0.7    0.1   55.0
nvme1n1         3900    2200  49000   12000     2.0    0.5     0.4      0.7    0.1   56.0

Interpretation: If w_await spikes during read scans, you’re seeing the “reads causing writes” interaction at the device queue. With HDDs, this effect is usually more dramatic.

Task 11: Look for metadata-heavy file counts and patterns

cr0x@server:~$ sudo zfs list -o name,used,refer,avail,mountpoint tank/buildcache
NAME            USED  REFER  AVAIL  MOUNTPOINT
tank/buildcache 12G   12G    1.7T   /srv/buildcache

cr0x@server:~$ find /srv/buildcache -type f | wc -l
2457812

Interpretation: Millions of files is where metadata behaviors stop being theoretical. Even if each atime update is “small,” the product of small times millions is what pages you at 2 a.m.

Task 12: Verify inheritance (avoid fixing the wrong dataset)

cr0x@server:~$ zfs get -r -o name,property,value,source atime tank | head -n 12
NAME                PROPERTY  VALUE  SOURCE
tank                atime     on     default
tank/buildcache      atime     off    local
tank/home            atime     on     inherited
tank/home/alice      atime     on     inherited
tank/home/bob        atime     on     inherited

Interpretation: atime is per dataset. Your “fix” might apply only to one subtree. That’s good when you want targeted change; it’s bad when you thought you fixed the whole pool.

Task 13: Check whether a snapshot / replication workflow relies on atime semantics

cr0x@server:~$ zfs list -t snapshot -o name,creation -s creation | tail -n 5
tank/buildcache@auto-2025-12-24-0900  Tue Dec 24 09:00 2025
tank/buildcache@auto-2025-12-24-1000  Tue Dec 24 10:00 2025
tank/buildcache@auto-2025-12-24-1100  Tue Dec 24 11:00 2025
tank/buildcache@auto-2025-12-24-1200  Tue Dec 24 12:00 2025
tank/buildcache@auto-2025-12-24-1300  Tue Dec 24 13:00 2025

Interpretation: Snapshots track block changes, not “access.” Disabling atime typically reduces change rate and can improve replication efficiency. If someone told you “we need atime so snapshots see changes,” that’s a misunderstanding.

Task 14: Validate that applications aren’t using atime for eviction policies

cr0x@server:~$ sudo grep -R "atime" -n /etc 2>/dev/null | head
/etc/updatedb.conf:23:PRUNEFS="... zfs ..."
/etc/cron.daily/tmpwatch:45:# uses mtime, not atime

Interpretation: This is crude, but it catches the “we have a cleanup job that uses atime” class of surprise. The real check is application configs and scripts; atime is a policy contract.

Three corporate-world stories from the atime trenches

1) Incident caused by a wrong assumption: “It’s read-only, so it can’t be the storage”

The ticket came in as a classic: CI pipelines timing out, build steps “hanging on uploads,” and a lot of finger-pointing at the network. The storage team got pulled in because the VM host’s pool graphs showed write IOPS climbing during business hours, even though the pipeline job was mostly reading dependencies and checking out source.

Someone had recently “standardized” dataset creation with a template that left atime=on everywhere. It wasn’t a malicious change—just a default that looked harmless. And on normal user home directories, it was harmless enough. On the build cache dataset with a couple million small files, it became a metronome of metadata churn.

The wrong assumption was that the workload was “read-only.” In reality, every file access was producing an atime update, which produced dirty metadata, which increased TXG sync work. The pool was fast, but the queueing was real and periodic; the writes competed with real artifact uploads and log writes. Latency spikes lined up with “innocent” scan steps like dependency resolution.

The fix was boring: disable atime on the cache dataset, then re-run the pipelines. The dramatic part was social, not technical: it took ten minutes to fix and two weeks to convince everyone that “read workload” can still write. Once they accepted that, a handful of other “mystery writes” became easy to explain.

Afterward, the team wrote a rule: datasets intended for caches or build trees are created with atime=off. Not because atime is bad, but because caches don’t need a diary.

2) An optimization that backfired: “Turn off atime everywhere” meets the compliance team

A different company, different flavor of pain. They had a file share used by multiple departments, including one group doing incident response and internal investigations. Storage performance was mediocre, and someone discovered the magic lever: atime=off. They applied it broadly, including on datasets that had been used (quietly) for evidentiary workflows.

The performance win was real. The mistake was assuming that atime was “only for old Unix nerds.” A few months later, an internal investigation tried to answer “who accessed these files and when.” They weren’t using atime as the only evidence, but it was part of the timeline triangulation. Suddenly, the access timestamps stopped updating. The investigators saw stale atimes and assumed the files were not being read, which sent them chasing the wrong leads for a while.

Technically, the filesystem was doing exactly what it was told. Organizationally, they had violated an implicit contract: access-time semantics had become part of a process. The optimization backfired not because it was wrong, but because it was applied indiscriminately.

The recovery wasn’t to turn atime back on everywhere. They created a dedicated dataset for the investigative share with atime=on and a documented reason. For general-purpose shares and caches, atime stayed off. The lesson: performance tuning is also systems design. If you change what truth is recorded, you need to notify the people who rely on that truth.

3) A boring but correct practice that saved the day: per-dataset policy and a change window

The best atime story I have is the one that didn’t become a story. A platform team ran OpenZFS for mixed workloads: databases, home directories, CI caches, and object storage gateways. They’d been burned before by “one-size-fits-all” tuning, so they maintained a small matrix of dataset profiles: db, home, cache, logs. Each profile had a few properties set intentionally, including atime.

One Friday, a security tool was rolled out that scanned source trees and dependency caches across the fleet. On systems where caches had atime disabled, the scan generated read load but didn’t create a metadata write storm. On systems where home directories kept atime enabled, the cost was acceptable because the file counts and access patterns were different. The rollout still caused load, but it stayed inside the budget.

What saved them was not a clever kernel tweak. It was governance: per-dataset properties set at creation time, a habit of checking zfs get before chasing ghosts, and a change window policy that allowed them to adjust dataset properties quickly without arguing about “what changed.” They could point at a profile, show the intent, and keep moving.

The moral is painfully unsexy: if you treat ZFS properties like part of the application contract—documented, reviewed, and consistent—you avoid a lot of midnight heroics. And you get to spend your weekends doing things other than reading iostat output like tea leaves.

Common mistakes, symptoms, and fixes

Mistake 1: Flipping atime at the pool root and assuming it applies everywhere

Symptom: You run zfs set atime=off tank and nothing changes for the problem workload.

Why: The workload lives on a child dataset with atime=on set locally, or it’s a different dataset entirely.

Fix: Identify the dataset for the mountpoint and check inheritance.

cr0x@server:~$ df -T /srv/buildcache
cr0x@server:~$ zfs get -o name,property,value,source atime tank/buildcache
cr0x@server:~$ zfs get -r -o name,property,value,source atime tank | grep buildcache

Mistake 2: Disabling atime where a process depends on it

Symptom: Cleanup/archiving jobs stop expiring files correctly, or investigative workflows complain about stale access timestamps.

Why: atime was being used as a policy input.

Fix: Restore atime on the datasets that require it, or redesign the job to use application logs, mtime, or explicit metadata rather than filesystem access time.

cr0x@server:~$ sudo zfs set atime=on tank/investigations
cr0x@server:~$ zfs get -o name,property,value,source atime tank/investigations

Mistake 3: Declaring victory after flipping atime without re-measuring

Symptom: The team celebrates, but the next day “slow writes” return.

Why: atime was a contributor, not the bottleneck; the real issue might be sync write latency, SLOG saturation, or a single slow vdev.

Fix: Run before/after measurements, and keep digging if latency still spikes.

cr0x@server:~$ zpool iostat -v tank 1
cr0x@server:~$ iostat -x 1

Mistake 4: Confusing “metadata writes” with “data corruption risk”

Symptom: Someone refuses to disable atime because “timestamps are critical” but can’t name a consumer.

Why: Conflating correctness with usefulness. ZFS will remain correct with atime off; you’re choosing not to record a specific fact.

Fix: Treat atime as a feature with stakeholders. Identify consumers; if none, disable it where performance matters.

Mistake 5: Benchmarking with tools that inadvertently update atime

Symptom: A “read benchmark” shows unexpected writes and worse performance than expected.

Why: The benchmark reads files and triggers atime updates, changing the workload.

Fix: Either disable atime for benchmarking realism, or ensure the benchmark’s semantics match production needs.

Checklists / step-by-step plan

Step-by-step plan: deciding whether to disable atime

1. Identify the dataset that backs the path the application uses.
2. Check current atime setting and whether it’s inherited or local.
3. Ask “who uses atime?” and require an answer that names an application/process.
4. Measure baseline: pool IOPS, latency, and TXG behavior during the problematic period.
5. Run a controlled read scan and observe whether writes increase.
6. If policy allows, toggle atime off on that dataset only.
7. Re-run the same scan and compare write IOPS and latency.
8. Monitor for side effects (cleanup scripts, forensic workflows, user expectations).
9. Document the dataset intent: “cache dataset; atime disabled for metadata churn reduction.”
10. Standardize creation: bake the property into provisioning so you don’t fight this battle again.

Operational checklist: when “slow writes” hits the pager

1. Confirm which dataset(s) are affected (df -T, zfs list).
2. Check pool health quickly (zpool status).
3. Watch pool I/O (zpool iostat -v 1) and device latency (iostat -x 1).
4. Determine if the workload is sync-heavy (application symptoms + zfs get sync).
5. Check dataset properties: atime, recordsize, compression, logbias.
6. Look for read scans triggering writes (controlled find/head test).
7. If atime is on and the workload is small-file/read-heavy, test atime=off (change management permitting).
8. Re-measure and capture evidence for the postmortem.

FAQ

1) Will disabling atime make ZFS “faster” in general?

Not universally. It mainly helps workloads with lots of file reads, especially small-file scans, where atime updates create a steady stream of metadata writes. For large sequential writes, atime usually isn’t the limiting factor.

2) Does atime=off affect mtime or ctime?

No. Disabling atime stops updating access time. mtime and ctime behave normally when you modify contents or metadata.

3) Is disabling atime dangerous?

It’s not dangerous to data integrity. It’s dangerous to assumptions. If a workflow depends on accurate access timestamps, turning atime off breaks that workflow quietly.

4) Can atime cause “slow writes” even if the app is writing, not reading?

Indirectly, yes. If the system is also doing lots of reads (indexers, antivirus, backups, monitoring agents) those reads can generate atime metadata writes that compete for the same TXG commit resources and I/O bandwidth, increasing latency for real writes.

5) Why do I see writes on the pool when users are “just browsing” a share?

Directory listings and file opens can trigger atime updates depending on client behavior and OS caching. On shares with lots of small files, “just browsing” can look like a metadata workload generator.

6) If I disable atime, do I need to remount?

No. It’s a ZFS dataset property. Set it with zfs set atime=off dataset, and the behavior changes immediately for new accesses.

7) Does disabling atime reduce snapshot size or replication bandwidth?

Often, yes—because you’re removing a stream of metadata changes that would otherwise dirty blocks. Snapshots capture changed blocks, and atime updates can count as changes.

8) Is atime the same thing as “relatime” on Linux?

They’re related ideas. relatime is a compromise behavior common on Linux filesystems. On ZFS, the reliable control surface is the ZFS dataset property atime. If you need specific semantics, validate with stat tests and zfs get.

9) How do I know if atime is the bottleneck or just noise?

Run a controlled read scan and watch for increased write IOPS and latency. Then toggle atime off and repeat. If write pressure drops and latency stabilizes, atime was at least a significant contributor. If nothing changes, keep looking at sync behavior, vdev imbalance, device latency, fragmentation, or CPU contention.

Conclusion

atime is one of those features that made perfect sense when disks were slow, filesystems were simpler, and “knowing what got read” felt like operational telemetry. In modern ZFS deployments—especially those dominated by caches, CI, containers, and endless small-file churn—atime can turn harmless reads into a background metadata write workload that steals IOPS, increases TXG pressure, and shows up to the application as “slow writes.”

The fix is often just one property change, but the decision is bigger than the toggle. Treat atime as a contract: enable it where someone truly needs access-time truth, and disable it where it merely burns performance to produce a timestamp nobody reads. Your storage will get faster, your graphs will get calmer, and you’ll spend less time explaining to executives how a read caused a write.