From owner-freebsd-fs@FreeBSD.ORG Sun Jun 9 17:14:08 2013 Return-Path: Delivered-To: fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4215B257 for ; Sun, 9 Jun 2013 17:14:08 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by mx1.freebsd.org (Postfix) with ESMTP id D9BF312FE for ; Sun, 9 Jun 2013 17:14:07 +0000 (UTC) Received: from mfilter10-d.gandi.net (mfilter10-d.gandi.net [217.70.178.139]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id BF177172089; Sun, 9 Jun 2013 19:13:56 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter10-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter10-d.gandi.net (mfilter10-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id NT9OyW5jv1WZ; Sun, 9 Jun 2013 19:13:55 +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 relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 97F37172067; Sun, 9 Jun 2013 19:13:54 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id DEBAF73A1C; Sun, 9 Jun 2013 10:13:51 -0700 (PDT) Date: Sun, 9 Jun 2013 10:13:51 -0700 From: Jeremy Chadwick To: Steven Hartland Subject: Re: Changing the default for ZFS atime to off? Message-ID: <20130609171351.GA41133@icarus.home.lan> References: <16FEF774EE8E4100AD2CAEC65276A49D@multiplay.co.uk> <2AC5E8F4-3AF1-4EA5-975D-741506AC70A5@my.gd> <3152D35416D047BCA14009F3108A8967@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3152D35416D047BCA14009F3108A8967@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 17:14:08 -0000 On Sun, Jun 09, 2013 at 05:39:42PM +0100, Steven Hartland wrote: > > ----- Original Message ----- From: "Damien Fleuriot" > To: "Steven Hartland" > Cc: > Sent: Sunday, June 09, 2013 11:39 AM > Subject: Re: Changing the default for ZFS atime to off? > > > > > >On 8 Jun 2013, at 20:54, "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 the change for reasons already raised by many > >people regarding the mbox file. > > > >Besides, if atime should default to off on 2 filesystems and on > >on all others, that would definitely create confusion. > > A very valid point. > > >Last, I believe it should be the admin's decision to turn atime > >off, just like it is his decision to turn compression on. > > Trying to play devils advocate here; compression is off by default > because it uses resources and doesn't give a benefit for all cases. Not to mention ZFS on FreeBSD, specifically WRT compression and dedup, still lack a separate priority class for their threads. Info on that: http://lists.freebsd.org/pipermail/freebsd-fs/2011-October/012718.html http://lists.freebsd.org/pipermail/freebsd-fs/2011-October/012726.html While the discussion about atime default is fine/good to have, there are bigger/more impacting than atime. (Compression and dedup are something people *really* want to use, and I understand -- hell, I'd be using compression if it weren't for the above problem. It's the sole blocker for me -- really). > Is that not the same as atime, and it should be an admins decision > to turn it on where it's wanted? While I understand you're playing devil's advocate, you will find I, as well as most BSD people (in my experience), tend to err on the side of caution. That means atime=on as a default. > >Don't mistake me, we turn atime=off on every box, every > >filesystem, even on Mac's HFS. > >Yet I believe defaulting it to off is a mistake. > > That's what prompted me to start this discussion. If a large portion > of users either disable atime already or would disable atime if they > knew about it, does that bring into question the current default? You've just encountered 1 user who sets atime=off on every box they admin/maintain. And you have me -- who has atime=on on every box he admins/maintains. If you're looking for a vote, you won't get one that satisfies everyone, nor the majority of FreeBSD users -- because most users are not subscribed to the mailing list, do not visit the forums, etc.. They install the OS + use it and live happily in their hobbit hole. I also have no idea how this would impact the commercial companies who rely on FreeBSD for their enterprise products. I imagine their feedback would (should? Matter of opinion) hold more weight. > Potentially a better solution would be to make atime an option > in the installer, as that helps educate admins that the option > exists, which is potentially the biggest issue here? As I've stated in some other threads (probably on -stable), I'm all for people adding options/checkboxes/etc. to bsdinstall to allow more granularity during installation (vs. having to do things after-the-fact or the "final shell" prior to rebooting). If someone wants to add an atime checkbox (checked == atime enabled) to the filesystem creation phase, that's fantastic. But I strongly feel that checkbox needs to default to checked/enabled, solely so there are no "unwanted surprises" since we have no idea what software they'll be using on the system. There is also (still) the concern of POSIX compliance, which the BSDs have historically been very strict about. I guess you can hash that out with Bruce. Honestly the relatime thing from Linux sounds like a decent compromise. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB |