From owner-freebsd-fs@FreeBSD.ORG Sun Jun 9 00:49:01 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 82AC2DB9 for ; Sun, 9 Jun 2013 00:49:01 +0000 (UTC) (envelope-from prvs=18721298a7=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 26ECD11CC for ; Sun, 9 Jun 2013 00:49:00 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50004223432.msg for ; Sun, 09 Jun 2013 01:48:59 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 09 Jun 2013 01:48:59 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=18721298a7=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: fs@freebsd.org Message-ID: <459E2FCADB4E40079066E4ABDBE47AFE@multiplay.co.uk> From: "Steven Hartland" To: "Jeremy Chadwick" References: <16FEF774EE8E4100AD2CAEC65276A49D@multiplay.co.uk> <20130608213331.GB18201@icarus.home.lan> <01719722FD8A41B4A4366611972A703A@multiplay.co.uk> <20130609001532.GA21540@icarus.home.lan> Subject: Re: Changing the default for ZFS atime to off? Date: Sun, 9 Jun 2013 01:48:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 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:49:01 -0000 ----- Original Message ----- From: "Jeremy Chadwick" >> 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@multiplay.co.uk.