Changing the default for ZFS atime to off?

[Chuck Burns]

On 6/8/2013 7:48 PM, Steven Hartland wrote:
> ----- Original Message ----- From: "Jeremy Chadwick" <jdc at koitsu.org>
>
>>> 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.
>
> The initial question was for ZFS, with UFS being secondary, but yes
> UFS isn't as easy as UFS.
>
>> 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.
>
> Could that not be covered by: /var /home for the common case at least?
>
>> 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
>
> So yes others think its a less than stellar idea ;-)
>
>>> 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.
>
> Its still seems simple to fix, see above.
>
>>> 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.
>
> Hasty no, just opening the idea up for discussion ;-)
>
>> 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.
>
> Yes I am aware, which is why I mentioned mail in my original post.
>
>> 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.
>
> I did already mention, we set atime=off on everything and have never had
> an issue, there's been similar mentions on the illumos list too.
>
> Now that doesn't mean its suitable for everthing, mail has already been
> mentioned, but thats still seems like a small set of use cases where its
> required.
>
> I guess where I'm coming from is making better for the vast majority.
>
> I believe there's no point in configuring for a rare case by default
> when it will make the much more common case worse.
>
>> 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.
>
> Everyone has their different uses of any OS, different experience etc,
> so things like this need open discussion IMO.
>
>    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.
>
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"

Plainly put, FreeBSD almost -never- changes the defaults.  They're 
steady, reliable, and pretty much set in stone.  It's the entire point.

If you want something where the defaults can change from day to day, 
then perhaps FreeBSD is not for you.  Personally, I don't mind having 
these defaults, as long as I can change them.

I mean, seriously, it really isn't all that hard to type "zfs set 
atime=off /some/pool/some/where"

-- 
Chuck Burns <break19 at gmail.com>