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: >>> >>> 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" > I'm looking at HEAD and I don't see "atime=off" for the /var dataset. Knowing that most folks (accepting the defaults) will store their mail in /var/mail ... does the concern over atime=off still exist? However, I did notice that before we go creating the /var dataset, we do set "atime=off" for the boot pool/dataset. Is inheritance at-play here? and /var is turning up with atime=off even though it's not specified? In that case, I certainly agree we should remove atime=off 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." > > - "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. > 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. > > 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. > 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 >> >> 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. > 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. > >> 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. > 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. > 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. > Cool. Thanks. -- Devin >> -----BEGIN PGP SIGNATURE----- >> Comment: GPGTools - https://urldefense.proofpoint.com/v1/url?u=https://gpgtools.org/&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=wXwxswJCpc3K%2Bud90aYI%2B82v%2Fyfs1mrTBzzeCe5XIXw%3D%0A&s=a9e0697e43ce4744f130997648d0104319221bba6924c28a9493ffa1cf6c3719 >> >> iQEcBAEBCgAGBQJShRf/AAoJEKrMn5R9npq5TYwH/j8RMceM4STpCAoMTAz8zkKn >> gpftMrdf37TnAPHxsXJaiZejlp+D85/a9lglYbB7e4WdgoDX9ZXA0QLtCEmEtN4y >> jz7KNa5oABq1GjDtwm2xQISDIe8yYI+znLSaHA9W18kCUZzi8AOj70C+O5gyY28c >> c3N3j6Y4EZP2wtQnWSgxvCwIX5p86Jvr3QvhrRuuMnKMCTAhzwIx24qcnA4EcTzn >> p9w25CKLtOzF23n3McodaUmibbBCHOYyraLQJ+eJGDXcsPBipls3oiWyiYuqpcQr >> 18QpLN1lS35RnULcb5pxnP9Oy9rAwxHKves9Mfu0UoWw3qTjSAf8gsGyu6QaMgc= >> =GjYk >> -----END PGP SIGNATURE----- >> >> _____________ >> 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. _____________ 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.Received on Thu Nov 14 2013 - 20:04:31 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:44 UTC