Date: Sat, 8 Jun 2013 17:15:32 -0700 From: Jeremy Chadwick <jdc@koitsu.org> To: Steven Hartland <killing@multiplay.co.uk> Cc: fs@freebsd.org Subject: Re: Changing the default for ZFS atime to off? Message-ID: <20130609001532.GA21540@icarus.home.lan> In-Reply-To: <01719722FD8A41B4A4366611972A703A@multiplay.co.uk> References: <16FEF774EE8E4100AD2CAEC65276A49D@multiplay.co.uk> <20130608213331.GB18201@icarus.home.lan> <01719722FD8A41B4A4366611972A703A@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jun 09, 2013 at 12:34:29AM +0100, Steven Hartland wrote: > ----- Original Message ----- From: "Jeremy Chadwick" > <jdc@koitsu.org> > To: "Steven Hartland" <smh@freebsd.org> > Cc: <fs@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@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130609001532.GA21540>