Changing the default for ZFS atime to off?

[Jeremy Chadwick]

On Sun, Jun 09, 2013 at 12:34:29AM +0100, Steven Hartland wrote:
> ----- Original Message ----- From: "Jeremy Chadwick"
> <jdc at koitsu.org>
> To: "Steven Hartland" <smh at freebsd.org>
> Cc: <fs at freebsd.org>
> Sent: Saturday, June 08, 2013 10:33 PM
> Subject: Re: Changing the default for ZFS atime to off?
> 
> 
> >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.
> >>
> >>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?
> >>
> >>If so what about UFS, same change?
> >
> >I **strongly** oppose this change, for one key reason: the classic
> >Berkeley UNIX mail spool format (known as "mbox"), which is still
> >predominantly used on most UNIX systems today.
> >
> >Mail clients which read mbox files require a combination of atime and
> >mtime to determine if new mail has arrived within the mailbox.  If
> >mtime > atime, then there's new mail.  Not all mail clients support
> >alternate methods of detection (for example mutt has check_mbox_size,
> >which has had bugs/problems in the past (Google check_mbox_size),
> >and is fallible in other ways).
> ..
> 
> To clarify when I say "by default" this only effect newly created
> pools / volumes, it would not effect any existing volumes and hence
> couldn't break existing installs.
> 
> As I mentioned there are apps, mainly mail focused ones, which rely
> on on atime, but thats easy to keep working by ensuring these are
> stored on volumes which do have atime=on.

The problem is that your proposed change (to set atime=off as the
default) means the administrator:

1. Has to be aware that the default is now atime=off going forward,
and thus,

2. Must manually set atime=on on filesystems where it matters, which may
also mean creating a separate filesystem just for certain
purposes/tasks (which may not be possible with UFS after-the-fact).

The reality of #1, I'm sorry to say, is that barring some kind of mass
announcement on every single FreeBSD mailing list (I don't mean just
-announce, I mean EVERY LIST) to inform people of this change, as well
as some gigantic 72pt font text on www.freebsd.org telling people, most
people are not going to know about it.  I know that reality doesn't work
in your favour, but it's how things are.  A single line in the Release
Notes is going to be overlooked.

I cannot even begin to cover all the situations/cases of #2, so I'll
just do a brain dump as I think:

i) ZFS: You might think this is as easy as creating a separate
filesystem that's for /var/mail -- it is not that simple.  Many people
have their mail delivered to mboxes within $HOME, i.e. ~user/Mail, and
/var/mail never gets used.  It worsens when you consider people are
being insane with ZFS filesystems, such as creating a separate
filesystem for every single user on the system.

ii) With UFS, you might think it's as easy as removing noatime from
/etc/fstab for /var, but it isn't -- same situation as (i).

iii) There is the situation with UFS and bsdinstall where you can choose
the "quick and easy" partitioning/filesystem setu results in one big /
and that's all.  Now the admin has to remove noatime from /etc/fstab and
basically loses any benefit noatime provided per your proposal.

iv) It is very common for setups to have two separate places for mail
storage, i.e. the default is /var/mail/username, but users with a
.forward and/or .procmailrc may be siphoning mail to $HOME/Mail/folder
instead.  So now you have two filesystems where atime needs to be
enabled.

v) Non-mail-related stuff, meaning there may actually be users and
administrators who rely upon access times to indicate something.

None of these touche base on what Bruce Evans stated too: that atime=on
by default is a requirement to be POSIX-compliant.  That's also
confirmed here at Wikipedia WRT stat(2) (which also mentions some other
software that relies on atime too):

http://en.wikipedia.org/wiki/Stat_%28system_call%29#Criticism_of_atime

> The messaging and changes to installers which support ZFS root
> installs, such as mfsbsd, would need to be included in this but
> I don't see that as a blocker.

See above -- I think you are assuming mail always gets stored on one
filesystem, which quite often not the case.

> I suggesting this now as it seems like its time to consider that
> the vast majority of systems don't need this option for all volumes
> and the performance and reliability of systems are in question if
> we don't consider it.

My personal feeling is that this is extremely hasty -- do we have any
idea how much software relies on atime?  Because I certainly don't.

Sorry for sounding rude (I don't mean to be, I just can't be bothered to
phrase it differently), but: were you yourself even aware that atime was
relied upon/used for classic UNIX mailboxes?  I get the impression you
weren't, which just strengthens my point.

For example, I use atime everywhere, simply because I do not know what
might break/stop working reliably if atime was disabled on some
filesystems.  I do not know the internals of every single daemon and
program on a system (does anyone?), so I must take the stance of
choosing stability/reliability.

All said and done: I do appreciate having this discussion, particularly
publicly on a list.  Too many "key changes" in FreeBSD in the past few
years have been results of closed-door meetings of sorts (private mail
or in-person *con meetings), so the fact this is public is good.

-- 
| Jeremy Chadwick                                   jdc at koitsu.org |
| UNIX Systems Administrator                http://jdc.koitsu.org/ |
| Making life hard for others since 1977.             PGP 4BD6C0CB |