Re: noatime on ufs2

Olivier Certner <olce@freebsd.org> wrote:

> I've mentioned your answer in another response to Lyndon Nerenberg when developing a more general argument that 'atime' is generally flawed for these kinds of use cases (finding the last use, finding files to backup, etc.).  It's true that the ability to deactivate 'atime''s implicit updates per-process would cater to more use cases, and it's an interesting idea.  Essentially, though, you can't guarantee that some applications, or simply administrators typing commands at the shell, are not going to throw away your precious access times, so can't rely (in a strong sense) on them.

Thanks for the heads-up - I've only now had a chance to catch up with the
thread.

You are of course right - atime can be affected by so many different things
that it can't be relied upon. I just thought a per-process method would be
a good compromise to avoid blanket atime changes across the system - both
for atime usefulness, and I/O, but as you say, as it's unreliable to rely
on anyway, this solution may be making things worse by giving a false sense
of reliability.

And to further bolster your point, whilst I have wished for more granuality
with respect to controlling atime updates, for years I've run everything
with noatime.. Even when I thought it was nice to keep atime relatively
accurate, I soon realised that I simply never used it anyway!

> Sure for backups and snapshots.  I agree you'd better have backup perimeters coinciding with file systems partitions and use snapshots to get the smoothest possible experience.  But snapshots alone do not guarantee the "correctness" of a backup (the ability to restart smoothly from it).

Yeah, it's more like a snapshot at the time of a power failure, but of
course, it's better than running on a live filesystem because a file may
be missed completely if moved whilst the backup is running.

But short of shutting everything down prior to taking the snapshot (I
remember at last job some very old machines without snapshotting or
decent db journalling capabilities being taken down for hours every
night, so that the whole backup ran in a minimal boot environment!),
I don't know of a cleaner solution... (though I'm sure some exist..
after all, live migrations between hosts are a thing these days.. I guess
I need to do some homework on the matter! :-) )

Thanks again, Jamie