Changing the default for ZFS atime to off?

[Bruce Evans]

On Sat, 8 Jun 2013 kpneal at pobox.com wrote:

> On Sat, Jun 08, 2013 at 07:54:04PM +0100, Steven Hartland wrote:
>> One of the first changes we make here when installing machines
>> here to changing atime=off on all ZFS pool roots.
>>
>> I know there are a few apps which can rely on atime updates
>> such as qmail and possibly postfix, but those seem like special
>> cases for which admins should enable atime instead of the other
>> way round.
>
> I believe mutt also uses them. Basically, any mail program using mbox mail
> folders uses them to correctly report which mailboxes have not been read
> yet.
>
> There are probably other cases as well. I don't think they should be
> discounted simply because nobody here who bothers to speak up runs into
> them.
>
> Turning off atime creates surprises for users.

Of course it can't be turned off by default.  It is specified by POSIX.

>> This is going to of particular interest for flash based storage
>> which should avoid unnessacary writes to reduce wear, but it will
>> also help improve performance in general.
>>
>> So what do people think is it worth considering changing the
>> default from atime=on to atime=off moving forward?
>
> I vote no. At least, don't change it unless the filesystem is actually on
> a flash device. Otherwise we risk breakage down the road because something
> that used to work doesn't work on a fresh FreeBSD install.
>
> Has anyone done any kind of study to see exactly how much I/O is caused
> by having atime updates be enabled? Does it _really_ make that much of
> a difference to performance, and would it _really_ help prolong the life
> of flash devices?

Not me, but I always mount with -noatime except when running POSIX
conformance tests, and also use my lazy update of inodes (IN_LAZYMOD)
for atime timestamps on all (ffs1) inodes.  IN_LAZYMOD is only used
for block and character vnodes in -current, so it became unused when
ffs stopped supporting device vnodes, and is still disabled for soft
updates so it is even more unused.

If the overhead were a real problem then file systems would use a special
atime cache and back it with a special device (perhaps /dev/null).
Sqillions of timestamps can be stored in compressed form in memory.
IN_LAZYMOD basically stores them in uncompressed form in vnodes, using
ordinary vnode caching.  Updates of the timestamps should use a log,
since if you have a million of them to sync then you want to write out
a contiguous log with 1 million entries and not do a million seeks.
Since they are very noncritical and even when critical are rarely critical
across unmounts and reboots, the log could be discarded at unmount and/or
remount to avoid the expense of replaying it.  In many uses it wouldn't
grow nearly as large as a million entries so it would then not need any
backing or physical i/o.

Most useless atime updates are probably for traversals of large
directory hierarchies.  There can easily be millions of files, but
millions of directories are not so common, and reading all the files
is even less common.  In POSIX, readdir() is not required to be
implemented using read(), so it could reasonably not be required to
set atime.  However, POSIX is careful to pessimize this by specifying
atime updates for readdir() too (readdir() may buffer its input, but
is required to mark atime for update whenever the directory is "actually
read").

Bruce