From owner-freebsd-fs@FreeBSD.ORG Sun Jun 9 00:15:54 2013 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 52A0A6D1 for ; Sun, 9 Jun 2013 00:15:54 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by mx1.freebsd.org (Postfix) with ESMTP id CE40C1FA0 for ; Sun, 9 Jun 2013 00:15:53 +0000 (UTC) Received: from mfilter16-d.gandi.net (mfilter16-d.gandi.net [217.70.178.144]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 67E4541C056; Sun, 9 Jun 2013 02:15:36 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter16-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter16-d.gandi.net (mfilter16-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id q9rpAwHWpxl3; Sun, 9 Jun 2013 02:15:34 +0200 (CEST) X-Originating-IP: 76.102.14.35 Received: from jdc.koitsu.org (c-76-102-14-35.hsd1.ca.comcast.net [76.102.14.35]) (Authenticated sender: jdc@koitsu.org) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 2F0BD41C054; Sun, 9 Jun 2013 02:15:34 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id 548CB73A1C; Sat, 8 Jun 2013 17:15:32 -0700 (PDT) Date: Sat, 8 Jun 2013 17:15:32 -0700 From: Jeremy Chadwick To: Steven Hartland Subject: Re: Changing the default for ZFS atime to off? Message-ID: <20130609001532.GA21540@icarus.home.lan> References: <16FEF774EE8E4100AD2CAEC65276A49D@multiplay.co.uk> <20130608213331.GB18201@icarus.home.lan> <01719722FD8A41B4A4366611972A703A@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01719722FD8A41B4A4366611972A703A@multiplay.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 00:15:54 -0000 On Sun, Jun 09, 2013 at 12:34:29AM +0100, Steven Hartland wrote: > ----- Original Message ----- From: "Jeremy Chadwick" > > To: "Steven Hartland" > Cc: > 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@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB |