Bug 16454

Since cc07895f95 ("sstate: Update mtime/atime for sig/siginfo files in
sstate_checkhashes()") sstate consistently refreshes both atime and mtime
whenever an object in the sstate cache is used. As a result, the mtime no
longer tells when an object was created, and atime == mtime for every used
object.

This was discussed on the list for the patch
"[v3] sstate: fix access to a cached object rewriting its modification time":
https://patchwork.yoctoproject.org/project/oe-core/patch/20260911070121.39436-1-michael.haener@siemens.com/
Richard asked for an analysis of the use cases a change could break and for
buy-in from other users before changing this. This bug is meant to collect
that.

Why atime-only would help:

- Shared caches can tell objects that are old but still in use from objects
  that were written once and never used again (atime > mtime). On our
  shared CI cache this showed that a few large recipes cause most of the
  never-reused data, which is not visible today.
- scripts/sstate-cache-management.py --remove-duplicated keeps the entry
  with the newest st_mtime. Today, building an older configuration last
  keeps its object and removes the newer one.

Analysis of the concerns raised:

1. Limited write access (shared caches with multiple users):
   Setting only the atime (touch -a, os.utime(ns=...), utimensat with
   UTIME_OMIT) requires file ownership. Setting both to "now" (touch,
   os.utime(path, None)) only requires write access. Verified on Linux with
   a world-writable file owned by root:
     touch /dev/null            -> ok
     touch -a /dev/null         -> Operation not permitted
   So an atime-only refresh must fall back to the current full touch on
   EPERM, otherwise objects in group-writable shared caches would never get
   a refreshed atime and an atime based cleanup would delete them.

2. noatime / relatime mounts:
   These only suppress implicit atime updates on read. An explicit
   utimensat() still sets the atime, so sstate's explicit refresh keeps
   working, as it does today.

3. NFS (ext4/zfs backed):
   The refresh is an explicit SETATTR, the same as today. It does not rely
   on the server updating atime on read.

4. Read-only caches:
   EROFS is ignored, same as today.

5. Users relying on mtime as "last used":
   - The autobuilder prunes its shared cache on the storage server with
     yocto-autobuilder-helper scripts/sstate-clean.sh:
       find .../pub/sstate \( -mtime +15 -a -atime +15 \) -type f \
         \( -name '*.tar*' -o -name '*.tgz*' \)
     An object is only removed when both timestamps are older than 15 days,
     so today either one keeps a used object alive. With an atime-only
     refresh the mtime stays at creation time, and after 15 days the atime
     alone decides. This is safe as long as the explicit atime refresh from
     the workers reliably reaches the server (NFS SETATTR on ZFS). If it is
     silently dropped (EPERM for files owned by another user, dataset or
     export settings), used objects would be pruned after 15 days where
     today the mtime would have saved them. This needs to be checked on the
     autobuilder setup before changing the default.
   - Other cleanup scripts using "find -mtime" alone would have to switch to
     "-atime". This needs a migration note.
   - meta/lib/oe/sstatesig.py find_siginfo() orders siginfo files by
     st_mtime (bitbake-diffsigs, bitbake -S printdiff). With atime-only the
     order would be by creation instead of last use.

Proposal:
Refresh only the atime and fall back to the current behaviour (atime and
mtime) when that is not permitted. Optionally make this configurable
(e.g. SSTATE_TOUCH_MTIME = "1" by default) so it can be enabled per
installation first.

Questions:
- Which other tools or CI setups rely on the mtime of sstate objects?
- Do the autobuilder workers access the sstate cache as the owner of the
  files, and does the ZFS/NFS setup keep an explicitly set atime?