From owner-freebsd-fs@FreeBSD.ORG Sun Jun 9 02:58:45 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 3FC07E2A for ; Sun, 9 Jun 2013 02:58:45 +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 D9DDA190C for ; Sun, 9 Jun 2013 02:58:44 +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 md50004224407.msg for ; Sun, 09 Jun 2013 03:58:43 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 09 Jun 2013 03:58:43 +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: <798D298E63D34820AF2D804E6123997B@multiplay.co.uk> From: "Steven Hartland" To: , References: <16FEF774EE8E4100AD2CAEC65276A49D@multiplay.co.uk> <20130608200522.GA77122@neutralgood.org> Subject: Re: Changing the default for ZFS atime to off? Date: Sun, 9 Jun 2013 03:58:38 +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 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 02:58:45 -0000 ----- Original Message ----- From: > 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. > > I believe mutt also uses them. Basically, any mail program using mbox mail > folders uses them to correctly report which mailboxes have not been read > yet. > > There are probably other cases as well. I don't think they should be > discounted simply because nobody here who bothers to speak up runs into > them. > > Turning off atime creates surprises for users. > >> 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? > > I vote no. At least, don't change it unless the filesystem is actually on > a flash device. Otherwise we risk breakage down the road because something > that used to work doesn't work on a fresh FreeBSD install. I don't think having different defaults for different disks would be a good thing as that would just cause confusion. Would updating the installers to enable atime on the volumes that require it be an acceptable solution? > Has anyone done any kind of study to see exactly how much I/O is caused > by having atime updates be enabled? Does it _really_ make that much of > a difference to performance, and would it _really_ help prolong the life > of flash devices? I've just done some a very basic tests here on an 8.3-RELEASE machine:- 1. make buildkernel # atime=on adds 2k writes totalling 27MB 2. find /usr/src # atime=on adds 100 writes totaling 3MB 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.