Date: Thu, 14 Nov 2013 21:04:07 +0000 From: "Teske, Devin" <Devin.Teske@fisglobal.com> To: Steven Hartland <killing@multiplay.co.uk> Cc: freebsd-fs <freebsd-fs@freebsd.org>, Devin Teske <dteske@freebsd.org>, "Teske, Devin" <Devin.Teske@fisglobal.com>, Allan Jude <freebsd@allanjude.com> Subject: Re: Defaults in 10.0 ZFS through bsdinstall Message-ID: <9A38EBE3-4012-4165-8655-03330277B04A@fisglobal.com> In-Reply-To: <0CBA81A49FFC447C9452C9A27BC2D017@multiplay.co.uk> References: <20131114173423.GA21761@blazingdot.com> <59A9B68B-4134-4217-83F3-B99759174EFE@fisglobal.com> <5285148E.6020903@allanjude.com> <3D3332FA-0ABF-4573-8E65-4E7FBB37100B@fisglobal.com> <1384462198.13183.47596065.6F8E7BCD@webmail.messagingengine.com> <0CBA81A49FFC447C9452C9A27BC2D017@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 14, 2013, at 12:59 PM, Steven Hartland wrote: > ----- Original Message ----- From: "Mark Felder" <feld@FreeBSD.org> > To: <freebsd-fs@freebsd.org> > Sent: Thursday, November 14, 2013 8:49 PM > Subject: Re: Defaults in 10.0 ZFS through bsdinstall >=20 >=20 >> On Thu, Nov 14, 2013, at 12:35, Teske, Devin wrote: >>> I have never heard a good argument for having atime on. The performance >>> penalty on ZFS is quite large, and it also makes your snapshots grow >>> constant. If you have a use for it, you can turn it on I guess. This >>> would be solved by having the dataset editor we're planning for 10.1 >> POLA and POSIX, even though it was a bad decision to invent atime :-) >> We've never turned atime off before and it would be a huge surprise to >> me, so I'd avocate that we let the admins who know what they're doing >> turn it off. I know many Linux distros install with noatime and/or >> nodiratime, but I'm 99% sure tools don't create filesystems with atime >> flagged to be off by default (tune2fs -O noatime). We don't even do inst= alls on UFS with atime disabled by default in fstab >> so why should we so suddenly change course for ZFS? >=20 > While I can see the reason some would argue to keep it on by default > I personally think this is a good change. >=20 > Why punish everyone forever due to poor design decision made in the dista= nt > past, just because a few select applications make use of said feature? >=20 > Is not a change which benefits the masses but comes with a slight > inconvenience of the select few, where they need to enable a feature > no one else needs a good idea? >=20 > Sure it needs to be clearly messaged so its not a surprise, but if thats > done I'm all for it. >=20 Sounds like a vote for enabling it where-needed by-default (e.g., /var as a= whole or more selectively, /var/mail) --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9A38EBE3-4012-4165-8655-03330277B04A>