Changing the default for ZFS atime to off?

[Steven Hartland]

----- 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 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.

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.

    Regards
    Steve

================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postmaster at multiplay.co.uk.