Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 14 Nov 2013 21:04:23 +0000
From:      "Teske, Devin" <Devin.Teske@fisglobal.com>
To:        Marcus Reid <marcus@blazingdot.com>
Cc:        freebsd-fs <freebsd-fs@freebsd.org>, Devin Teske <dteske@freebsd.org>, "Teske, Devin" <Devin.Teske@fisglobal.com>, FreeBSD Current <freebsd-current@freebsd.org>
Subject:   Re: Defaults in 10.0 ZFS through bsdinstall
Message-ID:  <B79068CE-A0CB-49B5-ABD1-5135A5F547BD@fisglobal.com>
In-Reply-To: <20131114203424.GA22267@blazingdot.com>
References:  <20131114173423.GA21761@blazingdot.com> <59A9B68B-4134-4217-83F3-B99759174EFE@fisglobal.com> <5285148E.6020903@allanjude.com> <3D3332FA-0ABF-4573-8E65-4E7FBB37100B@fisglobal.com> <20131114203424.GA22267@blazingdot.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On Nov 14, 2013, at 12:34 PM, Marcus Reid wrote:

> On Thu, Nov 14, 2013 at 06:35:43PM +0000, Teske, Devin wrote:
>> On Nov 14, 2013, at 10:21 AM, Allan Jude wrote:
>>> On 2013-11-14 9:34, Reid, Marcus wrote:
>>>=20
>>> Hi,
>>>=20
>>> I noticed a couple of things with the ZFS defaults that result from
>>> using the new installer in 10.0-BETA3.
>>>=20
>>> One, atime is turned off everywhere by default.  There was a thread
>>> on this list on June 8 with a subject of 'Changing the default for
>>> ZFS atime to off?', and from what I can tell the idea of turning off
>>> atime by default was not a popular one.
>>>=20
>>> Two, and probably less controversial, is that fletcher4 is specified
>>> exlicitly on the root pool, even though it is default (wouldn't you
>>> just want to go with the default, in case it changes?)
>>>=20
>>> Marcus
>>=20
>> I have never heard a good argument for having atime on.
>=20
> Can you address some of the issues that people brought up in the thread
> I mentioned earlier?  I'll summarize some:
>=20
>  - breaks some software (MTAs were mentioned), and the admin should
>    know when to turn atime on in those cases.
>=20
>  - "any mail program using mbox mail folders uses them to correctly
>    report which mailboxes have not been read yet"
>=20

I'm looking at HEAD and I don't see "atime=3Doff" for the /var dataset.
Knowing that most folks (accepting the defaults) will store their mail
in /var/mail ... does the concern over atime=3Doff still exist?

However, I did notice that before we go creating the /var dataset, we
do set "atime=3Doff" for the boot pool/dataset.

Is inheritance at-play here? and /var is turning up with atime=3Doff even
though it's not specified?

In that case, I certainly agree we should remove atime=3Doff from the last
place it is used -- the boot pool (nowhere else).




>  - "Of course it can't be turned off by default.  It is specified by
>    POSIX."
>=20
>  - "If the overhead were a real problem then file systems would use a
>    special atime cache"
>=20
>> The performance penalty on ZFS is quite large
>=20
> This is subjective, and if it were that bad it seems like other
> ZFS-based systems would have turned it off as well, or done something
> like caching/logging or relatime it to mitigate the performance hit.
>=20

I do recall discussions about bringing over relatime and making it the
default.

Allan was the one that brought up the performance hit...
Similarly where I $work, we turn it off where need performance (large
storage arrays and such).

I gather it's only a matter of time until relatime is default.



>> and it also makes your snapshots grow constant.
>=20
> This does not seem to be the case.  For example, if I snapshot
> zroot/usr/src and then tar it up, I generate a bunch of writes and the
> snapshot grows to 70.5MB.  However, when I tar it up a second time,
> there are writes but the snapshot remains 70.5MB.  It seems to use the
> same blocks for subsequent atime updates.
>=20
> If you made another snapshot, you would see more space used for that
> one, of course.
>=20

I'll defer to Allan to expand (was his recollection on snapshots)


>> 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
>>=20
>> Seems easy enough to turn on once installed. And like Allan says, the
>> editor for 10.1 would allow changing of the default.
>=20
> The same case could be made for turning it off, make that an option in
> the installer instead.
>=20

Fair enough. Good idea.



> Some people don't seem to use atime on a regular basis, but I use it a
> lot when troubleshooting things, and I think others do to when they get
> to the point where they realize how useful it is.
>=20
>> I'll add that if scripting it, you can (in current state for 10.0)
>> change the dataset options at-will.
>>=20
>> The fletcher4 thing is a leftover, from older versions of ZFS where
>> the default was fletcher2, I suppose we can remove it
>=20
> While I'm picking nits:
>=20
> There are some other locally set things that are default (exec set to on
> on zroot/var/tmp is one), that might just inherit that from zroot/var.
>=20

Need a +1 from Allan on that.


> Also, zroot doesn't appear to be mounted on /zroot, as it is on other
> ZFS-based systems.  This has the side-effect of newly created
> datasets not having a mountpoint by default, instead of /zroot/dataset.
> I don't know of the reason behind this change either.
>=20

Hmm, wonder if that's been fixed in HEAD already.


> I'm going to cross-post this to -current, this is a topic that I think
> warrants a wider audience.
>=20

Cool. Thanks.
--=20
Devin


>> -----BEGIN PGP SIGNATURE-----
>> Comment: GPGTools - https://urldefense.proofpoint.com/v1/url?u=3Dhttps:/=
/gpgtools.org/&k=3D%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=3DLTzUWWrRnz2iN3Pt=
HDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=3DwXwxswJCpc3K%2Bud90aYI%2B82v%2Fyfs1=
mrTBzzeCe5XIXw%3D%0A&s=3Da9e0697e43ce4744f130997648d0104319221bba6924c28a94=
93ffa1cf6c3719
>>=20
>> iQEcBAEBCgAGBQJShRf/AAoJEKrMn5R9npq5TYwH/j8RMceM4STpCAoMTAz8zkKn
>> gpftMrdf37TnAPHxsXJaiZejlp+D85/a9lglYbB7e4WdgoDX9ZXA0QLtCEmEtN4y
>> jz7KNa5oABq1GjDtwm2xQISDIe8yYI+znLSaHA9W18kCUZzi8AOj70C+O5gyY28c
>> c3N3j6Y4EZP2wtQnWSgxvCwIX5p86Jvr3QvhrRuuMnKMCTAhzwIx24qcnA4EcTzn
>> p9w25CKLtOzF23n3McodaUmibbBCHOYyraLQJ+eJGDXcsPBipls3oiWyiYuqpcQr
>> 18QpLN1lS35RnULcb5pxnP9Oy9rAwxHKves9Mfu0UoWw3qTjSAf8gsGyu6QaMgc=3D
>> =3DGjYk
>> -----END PGP SIGNATURE-----
>>=20
>> _____________
>> The information contained in this message is proprietary and/or confiden=
tial. If you are not the intended recipient, please: (i) delete the message=
 and all copies; (ii) do not disclose, distribute or use the message in any=
 manner; and (iii) notify the sender immediately. In addition, please be aw=
are that any message addressed to our domain is subject to archiving and re=
view by persons other than the intended recipient. Thank you.

_____________
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?B79068CE-A0CB-49B5-ABD1-5135A5F547BD>