Changing the default for ZFS atime to off?

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Changing the default for ZFS atime to off?

Steven Hartland-4
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.

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?

If so what about UFS, same change?

    Regards
    Steve


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changing the default for ZFS atime to off?

Teske, Devin

On Jun 8, 2013, at 11:54 AM, 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.
>
> 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?
>

+1 we turn it off on every ZFS filesystem (but we also don't use ZFS for root)


> If so what about UFS, same change?
>

We leave atime enabled for UFS root partition, /usr partition, /tmp partition, and /var

But if/when we do use UFS for non-system partitions, we turn it off there too.
--
Devin

_____________
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.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changing the default for ZFS atime to off?

Bruce Evans-4
In reply to this post by Steven Hartland-4
On Sat, 8 Jun 2013 [hidden email] wrote:

> 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.

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

>> 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.
>
> 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?

Not me, but I always mount with -noatime except when running POSIX
conformance tests, and also use my lazy update of inodes (IN_LAZYMOD)
for atime timestamps on all (ffs1) inodes.  IN_LAZYMOD is only used
for block and character vnodes in -current, so it became unused when
ffs stopped supporting device vnodes, and is still disabled for soft
updates so it is even more unused.

If the overhead were a real problem then file systems would use a special
atime cache and back it with a special device (perhaps /dev/null).
Sqillions of timestamps can be stored in compressed form in memory.
IN_LAZYMOD basically stores them in uncompressed form in vnodes, using
ordinary vnode caching.  Updates of the timestamps should use a log,
since if you have a million of them to sync then you want to write out
a contiguous log with 1 million entries and not do a million seeks.
Since they are very noncritical and even when critical are rarely critical
across unmounts and reboots, the log could be discarded at unmount and/or
remount to avoid the expense of replaying it.  In many uses it wouldn't
grow nearly as large as a million entries so it would then not need any
backing or physical i/o.

Most useless atime updates are probably for traversals of large
directory hierarchies.  There can easily be millions of files, but
millions of directories are not so common, and reading all the files
is even less common.  In POSIX, readdir() is not required to be
implemented using read(), so it could reasonably not be required to
set atime.  However, POSIX is careful to pessimize this by specifying
atime updates for readdir() too (readdir() may buffer its input, but
is required to mark atime for update whenever the directory is "actually
read").

Bruce
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changing the default for ZFS atime to off?

Jeremy Chadwick-4
In reply to this post by Steven Hartland-4
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.
>
> 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?
>
> If so what about UFS, same change?

I **strongly** oppose this change, for one key reason: the classic
Berkeley UNIX mail spool format (known as "mbox"), which is still
predominantly used on most UNIX systems today.

Mail clients which read mbox files require a combination of atime and
mtime to determine if new mail has arrived within the mailbox.  If
mtime > atime, then there's new mail.  Not all mail clients support
alternate methods of detection (for example mutt has check_mbox_size,
which has had bugs/problems in the past (Google check_mbox_size),
and is fallible in other ways).

Further points:

- FreeBSD comes with sendmail (MTA/MDA), which supports only mbox
  natively
- FreeBSD comes with mail/Mail/mailx (client), which only supports
  only mbox natively
- FreeBSD comes with biff/comsat, as well as from(1), which supports
  only mbox natively

FACT: We have no idea how prevalent these programs/features are used
throughout people's systems.  Any responses on freebsd-fs@ will be the
minority -- anyone familiar with FreeBSD knows that only when you
change (break) something do people start crawling out of the woodwork
(the recent fxp(4) situation on 8.4-RELEASE is proof).

What this means is that "by default" we have to assume that people are
reliant upon this type of functionality, and that by disabling it by
default (on any filesystem type) we will cause a very serious problem.
(Imagine telling your boss "the reason I didn't respond to your Email
promptly is because the FreeBSD people disabled atime by default and
thus new mail detection in my mail client stopped working").

Please read my blog post, circa 2009, for further details:

http://koitsu.wordpress.com/2009/10/29/unix-mail-format-annoyances/

Note: switching to Maildir is not an option, as I explain in my blog
(ZFS does not generally perform well with thousands of small files
in a single directory, or if multiple mailboxes, thousands of files
per multiple directories), and none of the above utilities that come
with FreeBSD support anything but mbox.

TL;DR -- Do not disable atime by default, you will anger many people.
Yes, their existing filesystems will still have atime=on, but the
instant the administrator builds a new box or upgrades + builds a new
filesystem......

--
| Jeremy Chadwick                                   [hidden email] |
| UNIX Systems Administrator                http://jdc.koitsu.org/ |
| Making life hard for others since 1977.             PGP 4BD6C0CB |

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changing the default for ZFS atime to off?

Steven Hartland

----- Original Message -----
From: "Jeremy Chadwick" <[hidden email]>
To: "Steven Hartland" <[hidden email]>
Cc: <[hidden email]>
Sent: Saturday, June 08, 2013 10:33 PM
Subject: Re: Changing the default for ZFS atime to off?


> 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.
>>
>> 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?
>>
>> If so what about UFS, same change?
>
> I **strongly** oppose this change, for one key reason: the classic
> Berkeley UNIX mail spool format (known as "mbox"), which is still
> predominantly used on most UNIX systems today.
>
> Mail clients which read mbox files require a combination of atime and
> mtime to determine if new mail has arrived within the mailbox.  If
> mtime > atime, then there's new mail.  Not all mail clients support
> alternate methods of detection (for example mutt has check_mbox_size,
> which has had bugs/problems in the past (Google check_mbox_size),
> and is fallible in other ways).
..

To clarify when I say "by default" this only effect newly created
pools / volumes, it would not effect any existing volumes and hence
couldn't break existing installs.

As I mentioned there are apps, mainly mail focused ones, which rely
on on atime, but thats easy to keep working by ensuring these are
stored on volumes which do have atime=on.

The messaging and changes to installers which support ZFS root
installs, such as mfsbsd, would need to be included in this but
I don't see that as a blocker.

I suggesting this now as it seems like its time to consider that
the vast majority of systems don't need this option for all volumes
and the performance and reliability of systems are in question if
we don't consider it.

    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 [hidden email].

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changing the default for ZFS atime to off?

Jeremy Chadwick-4
On Sun, Jun 09, 2013 at 12:34:29AM +0100, Steven Hartland wrote:

> ----- Original Message ----- From: "Jeremy Chadwick"
> <[hidden email]>
> To: "Steven Hartland" <[hidden email]>
> Cc: <[hidden email]>
> Sent: Saturday, June 08, 2013 10:33 PM
> Subject: Re: Changing the default for ZFS atime to off?
>
>
> >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.
> >>
> >>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?
> >>
> >>If so what about UFS, same change?
> >
> >I **strongly** oppose this change, for one key reason: the classic
> >Berkeley UNIX mail spool format (known as "mbox"), which is still
> >predominantly used on most UNIX systems today.
> >
> >Mail clients which read mbox files require a combination of atime and
> >mtime to determine if new mail has arrived within the mailbox.  If
> >mtime > atime, then there's new mail.  Not all mail clients support
> >alternate methods of detection (for example mutt has check_mbox_size,
> >which has had bugs/problems in the past (Google check_mbox_size),
> >and is fallible in other ways).
> ..
>
> To clarify when I say "by default" this only effect newly created
> pools / volumes, it would not effect any existing volumes and hence
> couldn't break existing installs.
>
> As I mentioned there are apps, mainly mail focused ones, which rely
> on on atime, but thats easy to keep working by ensuring these are
> stored on volumes which do have atime=on.

The problem is that your proposed change (to set atime=off as the
default) means the administrator:

1. Has to be aware that the default is now atime=off going forward,
and thus,

2. Must manually set atime=on on filesystems where it matters, which may
also mean creating a separate filesystem just for certain
purposes/tasks (which may not be possible with UFS after-the-fact).

The reality of #1, I'm sorry to say, is that barring some kind of mass
announcement on every single FreeBSD mailing list (I don't mean just
-announce, I mean EVERY LIST) to inform people of this change, as well
as some gigantic 72pt font text on www.freebsd.org telling people, most
people are not going to know about it.  I know that reality doesn't work
in your favour, but it's how things are.  A single line in the Release
Notes is going to be overlooked.

I cannot even begin to cover all the situations/cases of #2, so I'll
just do a brain dump as I think:

i) ZFS: You might think this is as easy as creating a separate
filesystem that's for /var/mail -- it is not that simple.  Many people
have their mail delivered to mboxes within $HOME, i.e. ~user/Mail, and
/var/mail never gets used.  It worsens when you consider people are
being insane with ZFS filesystems, such as creating a separate
filesystem for every single user on the system.

ii) With UFS, you might think it's as easy as removing noatime from
/etc/fstab for /var, but it isn't -- same situation as (i).

iii) There is the situation with UFS and bsdinstall where you can choose
the "quick and easy" partitioning/filesystem setu results in one big /
and that's all.  Now the admin has to remove noatime from /etc/fstab and
basically loses any benefit noatime provided per your proposal.

iv) It is very common for setups to have two separate places for mail
storage, i.e. the default is /var/mail/username, but users with a
.forward and/or .procmailrc may be siphoning mail to $HOME/Mail/folder
instead.  So now you have two filesystems where atime needs to be
enabled.

v) Non-mail-related stuff, meaning there may actually be users and
administrators who rely upon access times to indicate something.

None of these touche base on what Bruce Evans stated too: that atime=on
by default is a requirement to be POSIX-compliant.  That's also
confirmed here at Wikipedia WRT stat(2) (which also mentions some other
software that relies on atime too):

http://en.wikipedia.org/wiki/Stat_%28system_call%29#Criticism_of_atime

> The messaging and changes to installers which support ZFS root
> installs, such as mfsbsd, would need to be included in this but
> I don't see that as a blocker.

See above -- I think you are assuming mail always gets stored on one
filesystem, which quite often not the case.

> I suggesting this now as it seems like its time to consider that
> the vast majority of systems don't need this option for all volumes
> and the performance and reliability of systems are in question if
> we don't consider it.

My personal feeling is that this is extremely hasty -- do we have any
idea how much software relies on atime?  Because I certainly don't.

Sorry for sounding rude (I don't mean to be, I just can't be bothered to
phrase it differently), but: were you yourself even aware that atime was
relied upon/used for classic UNIX mailboxes?  I get the impression you
weren't, which just strengthens my point.

For example, I use atime everywhere, simply because I do not know what
might break/stop working reliably if atime was disabled on some
filesystems.  I do not know the internals of every single daemon and
program on a system (does anyone?), so I must take the stance of
choosing stability/reliability.

All said and done: I do appreciate having this discussion, particularly
publicly on a list.  Too many "key changes" in FreeBSD in the past few
years have been results of closed-door meetings of sorts (private mail
or in-person *con meetings), so the fact this is public is good.

--
| Jeremy Chadwick                                   [hidden email] |
| UNIX Systems Administrator                http://jdc.koitsu.org/ |
| Making life hard for others since 1977.             PGP 4BD6C0CB |

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changing the default for ZFS atime to off?

Steven Hartland
----- Original Message -----
From: "Jeremy Chadwick" <[hidden email]>

>> To clarify when I say "by default" this only effect newly created
>> pools / volumes, it would not effect any existing volumes and hence
>> couldn't break existing installs.
>>
>> As I mentioned there are apps, mainly mail focused ones, which rely
>> on on atime, but thats easy to keep working by ensuring these are
>> stored on volumes which do have atime=on.
>
> The problem is that your proposed change (to set atime=off as the
> default) means the administrator:
>
> 1. Has to be aware that the default is now atime=off going forward,
> and thus,
>
> 2. Must manually set atime=on on filesystems where it matters, which may
> also mean creating a separate filesystem just for certain
> purposes/tasks (which may not be possible with UFS after-the-fact).
>
> The reality of #1, I'm sorry to say, is that barring some kind of mass
> announcement on every single FreeBSD mailing list (I don't mean just
> -announce, I mean EVERY LIST) to inform people of this change, as well
> as some gigantic 72pt font text on www.freebsd.org telling people, most
> people are not going to know about it.  I know that reality doesn't work
> in your favour, but it's how things are.  A single line in the Release
> Notes is going to be overlooked.
>
> I cannot even begin to cover all the situations/cases of #2, so I'll
> just do a brain dump as I think:
>
> i) ZFS: You might think this is as easy as creating a separate
> filesystem that's for /var/mail -- it is not that simple.  Many people
> have their mail delivered to mboxes within $HOME, i.e. ~user/Mail, and
> /var/mail never gets used.  It worsens when you consider people are
> being insane with ZFS filesystems, such as creating a separate
> filesystem for every single user on the system.
>
> ii) With UFS, you might think it's as easy as removing noatime from
> /etc/fstab for /var, but it isn't -- same situation as (i).
>
> iii) There is the situation with UFS and bsdinstall where you can choose
> the "quick and easy" partitioning/filesystem setu results in one big /
> and that's all.  Now the admin has to remove noatime from /etc/fstab and
> basically loses any benefit noatime provided per your proposal.

The initial question was for ZFS, with UFS being secondary, but yes
UFS isn't as easy as UFS.
 
> iv) It is very common for setups to have two separate places for mail
> storage, i.e. the default is /var/mail/username, but users with a
> .forward and/or .procmailrc may be siphoning mail to $HOME/Mail/folder
> instead.  So now you have two filesystems where atime needs to be
> enabled.

Could that not be covered by: /var /home for the common case at least?

> v) Non-mail-related stuff, meaning there may actually be users and
> administrators who rely upon access times to indicate something.
>
> None of these touche base on what Bruce Evans stated too: that atime=on
> by default is a requirement to be POSIX-compliant.  That's also
> confirmed here at Wikipedia WRT stat(2) (which also mentions some other
> software that relies on atime too):
>
> http://en.wikipedia.org/wiki/Stat_%28system_call%29#Criticism_of_atime

So yes others think its a less than stellar idea ;-)

>> The messaging and changes to installers which support ZFS root
>> installs, such as mfsbsd, would need to be included in this but
>> I don't see that as a blocker.
>
> See above -- I think you are assuming mail always gets stored on one
> filesystem, which quite often not the case.

Its still seems simple to fix, see above.

>> I suggesting this now as it seems like its time to consider that
>> the vast majority of systems don't need this option for all volumes
>> and the performance and reliability of systems are in question if
>> we don't consider it.
>
> My personal feeling is that this is extremely hasty -- do we have any
> idea how much software relies on atime?  Because I certainly don't.

Hasty no, just opening the idea up for discussion ;-)

> Sorry for sounding rude (I don't mean to be, I just can't be bothered to
> phrase it differently), but: were you yourself even aware that atime was
> relied upon/used for classic UNIX mailboxes?  I get the impression you
> weren't, which just strengthens my point.

Yes I am aware, which is why I mentioned mail in my original post.

> For example, I use atime everywhere, simply because I do not know what
> might break/stop working reliably if atime was disabled on some
> filesystems.  I do not know the internals of every single daemon and
> program on a system (does anyone?), so I must take the stance of
> choosing stability/reliability.

I did already mention, we set atime=off on everything and have never had
an issue, there's been similar mentions on the illumos list too.

Now that doesn't mean its suitable for everthing, mail has already been
mentioned, but thats still seems like a small set of use cases where its
required.

I guess where I'm coming from is making better for the vast majority.

I believe there's no point in configuring for a rare case by default
when it will make the much more common case worse.

> All said and done: I do appreciate having this discussion, particularly
> publicly on a list.  Too many "key changes" in FreeBSD in the past few
> years have been results of closed-door meetings of sorts (private mail
> or in-person *con meetings), so the fact this is public is good.

Everyone has their different uses of any OS, different experience etc,
so things like this need open discussion IMO.

    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 [hidden email].

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changing the default for ZFS atime to off?

Chris Ross

  I agree strongly with Jeremy's general opinion.  But, am far less established
in the community, so only wanted to make a couple of small points.

On Jun 8, 2013, at 20:48 , "Steven Hartland" <[hidden email]> wrote:
> I guess where I'm coming from is making better for the vast majority.
>
> I believe there's no point in configuring for a rare case by default
> when it will make the much more common case worse.

  I think the point being made, and certainly in my mind reading this thread,
is that you're considering the "rare" case to be more rare than you factually
know it to be, and more importantly (IMO), you're considering "worse" on
something that I consider a very small issue.  I understand the reasons we
choose to turn off atime (by adding it to the kernel, at the time, in 1994) at
UUNET for the USENET filesystems.  It was just too much activity.  But, for
a less than 110% active system, and given the relatively small number of things
that are accessed far more often than they're updated, I just don't think it's that
big of an issue.

  And, yes, I'm aware of the flash write issue, and I side with turning off there,
though I wouldn't be default.  (And, defaulting filesystem parameters based on
some impression of the underlying hardware seems risky at best anyway.)

  I think there are a small number of cases where it's an issue, and those people,
yourself included, already know how to solve the problem.  Myself, personally,
running only small systems, have never turned off atime updates.  Don't feel
any need to.  For specific heavy-load production systems, _everything_ is
looked at with a fine-toothed-comb.  No reason to "default" something that
only those systems need.

>> All said and done: I do appreciate having this discussion, particularly
>> publicly on a list.  Too many "key changes" in FreeBSD in the past few
>> years have been results of closed-door meetings of sorts (private mail
>> or in-person *con meetings), so the fact this is public is good.
>
> Everyone has their different uses of any OS, different experience etc,
> so things like this need open discussion IMO.

  I agree very much, and while my opinions may not match many others, I've
been very pleased to read this discussion.  Thank you for bringing it up.

                                                - Chris


_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changing the default for ZFS atime to off?

Steven Hartland
In reply to this post by Steven Hartland-4
----- Original Message -----
From: <[hidden email]>


> 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 [hidden email].

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changing the default for ZFS atime to off?

Adam Vande More
In reply to this post by Jeremy Chadwick-4
On Sat, Jun 8, 2013 at 4:33 PM, Jeremy Chadwick <[hidden email]> wrote:

> I **strongly** oppose this change, for one key reason: the classic
> Berkeley UNIX mail spool format (known as "mbox"), which is still
> predominantly used on most UNIX systems today.
>
> Mail clients which read mbox files require a combination of atime and
> mtime to determine if new mail has arrived within the mailbox.  If
> mtime > atime, then there's new mail.  Not all mail clients support
> alternate methods of detection (for example mutt has check_mbox_size,
> which has had bugs/problems in the past (Google check_mbox_size),
> and is fallible in other ways).
>
> Further points:
>
> - FreeBSD comes with sendmail (MTA/MDA), which supports only mbox
>   natively
> - FreeBSD comes with mail/Mail/mailx (client), which only supports
>   only mbox natively
> - FreeBSD comes with biff/comsat, as well as from(1), which supports
>   only mbox natively
>

Most modern linuce use relatime eg the benefits of noatime and preserving
functionality for mail stuff.

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Power_Management_Guide/Relatime.html

--
Adam Vande More
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changing the default for ZFS atime to off?

Xin LI-5
In reply to this post by Steven Hartland-4
I'd suggest implementing relative atime in VFS layer first:

https://github.com/delphij/freebsd/commit/6a199821fbdbf424027499d4a0f8f113f6943e16
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changing the default for ZFS atime to off?

Steven Hartland
In reply to this post by Adam Vande More

----- Original Message -----
From: "Adam Vande More" <[hidden email]>
To: "Jeremy Chadwick" <[hidden email]>
Cc: "Steven Hartland" <[hidden email]>; <[hidden email]>
Sent: Sunday, June 09, 2013 3:59 AM
Subject: Re: Changing the default for ZFS atime to off?


> On Sat, Jun 8, 2013 at 4:33 PM, Jeremy Chadwick <[hidden email]> wrote:
>
>> I **strongly** oppose this change, for one key reason: the classic
>> Berkeley UNIX mail spool format (known as "mbox"), which is still
>> predominantly used on most UNIX systems today.
>>
>> Mail clients which read mbox files require a combination of atime and
>> mtime to determine if new mail has arrived within the mailbox.  If
>> mtime > atime, then there's new mail.  Not all mail clients support
>> alternate methods of detection (for example mutt has check_mbox_size,
>> which has had bugs/problems in the past (Google check_mbox_size),
>> and is fallible in other ways).
>>
>> Further points:
>>
>> - FreeBSD comes with sendmail (MTA/MDA), which supports only mbox
>>   natively
>> - FreeBSD comes with mail/Mail/mailx (client), which only supports
>>   only mbox natively
>> - FreeBSD comes with biff/comsat, as well as from(1), which supports
>>   only mbox natively
>>
>
> Most modern linuce use relatime eg the benefits of noatime and preserving
> functionality for mail stuff.
>
> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Power_Management_Guide/Relatime.html

Now thats a clever idea, like it.

    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 [hidden email].

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changing the default for ZFS atime to off?

Damien Fleuriot-2
In reply to this post by Steven Hartland-4

On 8 Jun 2013, at 20:54, "Steven Hartland" <[hidden email]> 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.
>
> 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?
>
> If so what about UFS, same change?
>


I strongly oppose the change for reasons already raised by many people regarding the mbox file.

Besides, if atime should default to off on 2 filesystems and on on all others, that would definitely create confusion.

Last, I believe it should be the admin's decision to turn atime off, just like it is his decision to turn compression on.

Don't mistake me, we turn atime=off on every box, every filesystem, even on Mac's HFS.
Yet I believe defaulting it to off is a mistake.
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changing the default for ZFS atime to off?

Lee Dilkie-2
In reply to this post by Steven Hartland

On 6/8/2013 11:14 PM, Steven Hartland wrote:

>
>> Most modern linuce use relatime eg the benefits of noatime and
>> preserving
>> functionality for mail stuff.
>>
>> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Power_Management_Guide/Relatime.html
>>
>
> Now thats a clever idea, like it.
>

Indeed... very clever. caching atime itself. I like it too.

-lee

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changing the default for ZFS atime to off?

Adam Vande More
In reply to this post by Xin LI-5
On Sat, Jun 8, 2013 at 10:04 PM, Xin LI <[hidden email]> wrote:

> I'd suggest implementing relative atime in VFS layer first:
>
>
> https://github.com/delphij/freebsd/commit/6a199821fbdbf424027499d4a0f8f113f6943e16


Cool, looks like you were already on this. I would offer to test some, but
I'm pretty much ZFS only at this point.  I imagine there would be much less
objections to defaulting to relatime rather than noatime.  AFAIK, relatime
doesn't break any major tools.



--
Adam Vande More
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changing the default for ZFS atime to off?

Steven Hartland
In reply to this post by Damien Fleuriot-2

----- Original Message -----
From: "Damien Fleuriot" <[hidden email]>
To: "Steven Hartland" <[hidden email]>
Cc: <[hidden email]>
Sent: Sunday, June 09, 2013 11:39 AM
Subject: Re: Changing the default for ZFS atime to off?


>
> On 8 Jun 2013, at 20:54, "Steven Hartland" <[hidden email]> 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.
>>
>> 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?
>>
>> If so what about UFS, same change?
>
> I strongly oppose the change for reasons already raised by many
> people regarding the mbox file.
>
> Besides, if atime should default to off on 2 filesystems and on
> on all others, that would definitely create confusion.

A very valid point.

> Last, I believe it should be the admin's decision to turn atime
> off, just like it is his decision to turn compression on.

Trying to play devils advocate here; compression is off by default
because it uses resources and doesn't give a benefit for all cases.

Is that not the same as atime, and it should be an admins decision
to turn it on where it's wanted?

> Don't mistake me, we turn atime=off on every box, every
> filesystem, even on Mac's HFS.
> Yet I believe defaulting it to off is a mistake.

That's what prompted me to start this discussion. If a large portion
of users either disable atime already or would disable atime if they
knew about it, does that bring into question the current default?

Potentially a better solution would be to make atime an option
in the installer, as that helps educate admins that the option
exists, which is potentially the biggest issue here?

    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 [hidden email].

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changing the default for ZFS atime to off?

Steven Hartland
In reply to this post by Xin LI-5
----- Original Message -----
From: "Xin LI" <[hidden email]>

> I'd suggest implementing relative atime in VFS layer first:
>
> https://github.com/delphij/freebsd/commit/6a199821fbdbf424027499d4a0f8f113f6943e16
>

Cool, its this something your looking to commit to HEAD Xin?

    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 [hidden email].

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changing the default for ZFS atime to off?

Jeremy Chadwick-4
In reply to this post by Steven Hartland
On Sun, Jun 09, 2013 at 05:39:42PM +0100, Steven Hartland wrote:

>
> ----- Original Message ----- From: "Damien Fleuriot" <[hidden email]>
> To: "Steven Hartland" <[hidden email]>
> Cc: <[hidden email]>
> Sent: Sunday, June 09, 2013 11:39 AM
> Subject: Re: Changing the default for ZFS atime to off?
>
>
> >
> >On 8 Jun 2013, at 20:54, "Steven Hartland" <[hidden email]> 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.
> >>
> >>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?
> >>
> >>If so what about UFS, same change?
> >
> >I strongly oppose the change for reasons already raised by many
> >people regarding the mbox file.
> >
> >Besides, if atime should default to off on 2 filesystems and on
> >on all others, that would definitely create confusion.
>
> A very valid point.
>
> >Last, I believe it should be the admin's decision to turn atime
> >off, just like it is his decision to turn compression on.
>
> Trying to play devils advocate here; compression is off by default
> because it uses resources and doesn't give a benefit for all cases.

Not to mention ZFS on FreeBSD, specifically WRT compression and dedup,
still lack a separate priority class for their threads.  Info on that:

http://lists.freebsd.org/pipermail/freebsd-fs/2011-October/012718.html
http://lists.freebsd.org/pipermail/freebsd-fs/2011-October/012726.html

While the discussion about atime default is fine/good to have, there are
bigger/more impacting than atime.  (Compression and dedup are something
people *really* want to use, and I understand -- hell, I'd be using
compression if it weren't for the above problem.  It's the sole blocker
for me -- really).

> Is that not the same as atime, and it should be an admins decision
> to turn it on where it's wanted?

While I understand you're playing devil's advocate, you will find I, as
well as most BSD people (in my experience), tend to err on the side of
caution.  That means atime=on as a default.

> >Don't mistake me, we turn atime=off on every box, every
> >filesystem, even on Mac's HFS.
> >Yet I believe defaulting it to off is a mistake.
>
> That's what prompted me to start this discussion. If a large portion
> of users either disable atime already or would disable atime if they
> knew about it, does that bring into question the current default?

You've just encountered 1 user who sets atime=off on every box they
admin/maintain.

And you have me -- who has atime=on on every box he admins/maintains.

If you're looking for a vote, you won't get one that satisfies everyone,
nor the majority of FreeBSD users -- because most users are not
subscribed to the mailing list, do not visit the forums, etc..  They
install the OS + use it and live happily in their hobbit hole.

I also have no idea how this would impact the commercial companies who
rely on FreeBSD for their enterprise products.  I imagine their feedback
would (should?  Matter of opinion) hold more weight.

> Potentially a better solution would be to make atime an option
> in the installer, as that helps educate admins that the option
> exists, which is potentially the biggest issue here?

As I've stated in some other threads (probably on -stable), I'm all for
people adding options/checkboxes/etc. to bsdinstall to allow more
granularity during installation (vs. having to do things after-the-fact
or the "final shell" prior to rebooting).  If someone wants to add an
atime checkbox (checked == atime enabled) to the filesystem creation
phase, that's fantastic.

But I strongly feel that checkbox needs to default to checked/enabled,
solely so there are no "unwanted surprises" since we have no idea what
software they'll be using on the system.

There is also (still) the concern of POSIX compliance, which the BSDs
have historically been very strict about.  I guess you can hash that out
with Bruce.

Honestly the relatime thing from Linux sounds like a decent compromise.

--
| Jeremy Chadwick                                   [hidden email] |
| UNIX Systems Administrator                http://jdc.koitsu.org/ |
| Making life hard for others since 1977.             PGP 4BD6C0CB |

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changing the default for ZFS atime to off?

Chuck Burns-2
In reply to this post by Steven Hartland
On 6/8/2013 7:48 PM, Steven Hartland wrote:

> ----- Original Message ----- From: "Jeremy Chadwick" <[hidden email]>
>
>>> To clarify when I say "by default" this only effect newly created
>>> pools / volumes, it would not effect any existing volumes and hence
>>> couldn't break existing installs.
>>>
>>> As I mentioned there are apps, mainly mail focused ones, which rely
>>> on on atime, but thats easy to keep working by ensuring these are
>>> stored on volumes which do have atime=on.
>>
>> The problem is that your proposed change (to set atime=off as the
>> default) means the administrator:
>>
>> 1. Has to be aware that the default is now atime=off going forward,
>> and thus,
>>
>> 2. Must manually set atime=on on filesystems where it matters, which may
>> also mean creating a separate filesystem just for certain
>> purposes/tasks (which may not be possible with UFS after-the-fact).
>>
>> The reality of #1, I'm sorry to say, is that barring some kind of mass
>> announcement on every single FreeBSD mailing list (I don't mean just
>> -announce, I mean EVERY LIST) to inform people of this change, as well
>> as some gigantic 72pt font text on www.freebsd.org telling people, most
>> people are not going to know about it.  I know that reality doesn't work
>> in your favour, but it's how things are.  A single line in the Release
>> Notes is going to be overlooked.
>>
>> I cannot even begin to cover all the situations/cases of #2, so I'll
>> just do a brain dump as I think:
>>
>> i) ZFS: You might think this is as easy as creating a separate
>> filesystem that's for /var/mail -- it is not that simple.  Many people
>> have their mail delivered to mboxes within $HOME, i.e. ~user/Mail, and
>> /var/mail never gets used.  It worsens when you consider people are
>> being insane with ZFS filesystems, such as creating a separate
>> filesystem for every single user on the system.
>>
>> ii) With UFS, you might think it's as easy as removing noatime from
>> /etc/fstab for /var, but it isn't -- same situation as (i).
>>
>> iii) There is the situation with UFS and bsdinstall where you can choose
>> the "quick and easy" partitioning/filesystem setu results in one big /
>> and that's all.  Now the admin has to remove noatime from /etc/fstab and
>> basically loses any benefit noatime provided per your proposal.
>
> The initial question was for ZFS, with UFS being secondary, but yes
> UFS isn't as easy as UFS.
>
>> iv) It is very common for setups to have two separate places for mail
>> storage, i.e. the default is /var/mail/username, but users with a
>> .forward and/or .procmailrc may be siphoning mail to $HOME/Mail/folder
>> instead.  So now you have two filesystems where atime needs to be
>> enabled.
>
> Could that not be covered by: /var /home for the common case at least?
>
>> v) Non-mail-related stuff, meaning there may actually be users and
>> administrators who rely upon access times to indicate something.
>>
>> None of these touche base on what Bruce Evans stated too: that atime=on
>> by default is a requirement to be POSIX-compliant.  That's also
>> confirmed here at Wikipedia WRT stat(2) (which also mentions some other
>> software that relies on atime too):
>>
>> http://en.wikipedia.org/wiki/Stat_%28system_call%29#Criticism_of_atime
>
> So yes others think its a less than stellar idea ;-)
>
>>> The messaging and changes to installers which support ZFS root
>>> installs, such as mfsbsd, would need to be included in this but
>>> I don't see that as a blocker.
>>
>> See above -- I think you are assuming mail always gets stored on one
>> filesystem, which quite often not the case.
>
> Its still seems simple to fix, see above.
>
>>> I suggesting this now as it seems like its time to consider that
>>> the vast majority of systems don't need this option for all volumes
>>> and the performance and reliability of systems are in question if
>>> we don't consider it.
>>
>> My personal feeling is that this is extremely hasty -- do we have any
>> idea how much software relies on atime?  Because I certainly don't.
>
> Hasty no, just opening the idea up for discussion ;-)
>
>> Sorry for sounding rude (I don't mean to be, I just can't be bothered to
>> phrase it differently), but: were you yourself even aware that atime was
>> relied upon/used for classic UNIX mailboxes?  I get the impression you
>> weren't, which just strengthens my point.
>
> Yes I am aware, which is why I mentioned mail in my original post.
>
>> For example, I use atime everywhere, simply because I do not know what
>> might break/stop working reliably if atime was disabled on some
>> filesystems.  I do not know the internals of every single daemon and
>> program on a system (does anyone?), so I must take the stance of
>> choosing stability/reliability.
>
> I did already mention, we set atime=off on everything and have never had
> an issue, there's been similar mentions on the illumos list too.
>
> Now that doesn't mean its suitable for everthing, mail has already been
> mentioned, but thats still seems like a small set of use cases where its
> required.
>
> I guess where I'm coming from is making better for the vast majority.
>
> I believe there's no point in configuring for a rare case by default
> when it will make the much more common case worse.
>
>> All said and done: I do appreciate having this discussion, particularly
>> publicly on a list.  Too many "key changes" in FreeBSD in the past few
>> years have been results of closed-door meetings of sorts (private mail
>> or in-person *con meetings), so the fact this is public is good.
>
> Everyone has their different uses of any OS, different experience etc,
> so things like this need open discussion IMO.
>
>    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 [hidden email].
>
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "[hidden email]"

Plainly put, FreeBSD almost -never- changes the defaults.  They're
steady, reliable, and pretty much set in stone.  It's the entire point.

If you want something where the defaults can change from day to day,
then perhaps FreeBSD is not for you.  Personally, I don't mind having
these defaults, as long as I can change them.

I mean, seriously, it really isn't all that hard to type "zfs set
atime=off /some/pool/some/where"

--
Chuck Burns <[hidden email]>

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Changing the default for ZFS atime to off?

Chuck Burns-2
In reply to this post by Damien Fleuriot-2
On 6/9/2013 5:39 AM, Damien Fleuriot wrote:

> On 8 Jun 2013, at 20:54, "Steven Hartland" <[hidden email]> 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.
>>
>> 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?
>>
>> If so what about UFS, same change?
>>
>
> I strongly oppose the change for reasons already raised by many people regarding the mbox file.
>
> Besides, if atime should default to off on 2 filesystems and on on all others, that would definitely create confusion.
>
> Last, I believe it should be the admin's decision to turn atime off, just like it is his decision to turn compression on.
>
> Don't mistake me, we turn atime=off on every box, every filesystem, even on Mac's HFS.
> Yet I believe defaulting it to off is a mistake.
> _______________________________________________
> [hidden email] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "[hidden email]"

+1 here.  I, too, usually turn it off, and doing so isn't especially
difficult.  Changing DEFAULTS is only good when the defaults actually
break stuff.

--
Chuck Burns <[hidden email]>

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "[hidden email]"
12
Loading...