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:
> > 
> > Hi,
> > 
> > I noticed a couple of things with the ZFS defaults that result from
> > using the new installer in 10.0-BETA3.
> > 
> > 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.
> > 
> > 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?)
> > 
> > Marcus
> I have never heard a good argument for having atime on.

Can you address some of the issues that people brought up in the thread
I mentioned earlier?  I'll summarize some:

  - breaks some software (MTAs were mentioned), and the admin should
    know when to turn atime on in those cases.

  - "any mail program using mbox mail folders uses them to correctly
    report which mailboxes have not been read yet"

  - "Of course it can't be turned off by default.  It is specified by

  - "If the overhead were a real problem then file systems would use a
    special atime cache"

> The performance penalty on ZFS is quite large

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.

> and it also makes your snapshots grow constant.

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.

If you made another snapshot, you would see more space used for that
one, of course.

> 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
> Seems easy enough to turn on once installed. And like Allan says, the
> editor for 10.1 would allow changing of the default.

The same case could be made for turning it off, make that an option in
the installer instead.

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.

> I'll add that if scripting it, you can (in current state for 10.0)
> change the dataset options at-will.
> The fletcher4 thing is a leftover, from older versions of ZFS where
> the default was fletcher2, I suppose we can remove it

While I'm picking nits:

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.

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.

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



> Let me put something together.
> - -- 
> Devin
> Comment: GPGTools - https://gpgtools.org
> gpftMrdf37TnAPHxsXJaiZejlp+D85/a9lglYbB7e4WdgoDX9ZXA0QLtCEmEtN4y
> jz7KNa5oABq1GjDtwm2xQISDIe8yYI+znLSaHA9W18kCUZzi8AOj70C+O5gyY28c
> c3N3j6Y4EZP2wtQnWSgxvCwIX5p86Jvr3QvhrRuuMnKMCTAhzwIx24qcnA4EcTzn
> p9w25CKLtOzF23n3McodaUmibbBCHOYyraLQJ+eJGDXcsPBipls3oiWyiYuqpcQr
> 18QpLN1lS35RnULcb5pxnP9Oy9rAwxHKves9Mfu0UoWw3qTjSAf8gsGyu6QaMgc=
> =GjYk
> _____________
> The information contained in this message is proprietary and/or confidential. 
> 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 aware that 
> any message addressed to our domain is subject to archiving and review by 
> persons other than the intended recipient. Thank you.
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to