From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: default mount options 3.10
Date: Sun, 25 Aug 2013 10:29:25 +0000 (UTC) [thread overview]
Message-ID: <pan$1a1a3$f154c1a1$c83dacd2$30613a32@cox.net> (raw)
In-Reply-To: pan$348ab$94e882cf$7b189911$f0786ffb@cox.net
Duncan posted on Sat, 24 Aug 2013 12:23:18 +0000 as excerpted:
> Martin Steigerwald posted on Fri, 23 Aug 2013 14:58:07 +0200 as
> excerpted:
>
>> Am Freitag, 23. August 2013, 12:29:42 schrieb Xavier Bassery:
>>> On Fri, 23 Aug 2013 11:38:56 +0200
>>>
>>> David Kofler <dkofler92@googlemail.com> wrote:
[mount-option discussion]
One that I omitted in my previous discussion because it's not btrfs
specific, but that makes a rather larger difference than normal on btrfs,
especially with lots of snapshots, is noatime. Unfortunately, for legacy
reasons, that can't be the default, but unless you're running mutt (which
needs atime to track read messages except with mbox) or something
similar, there really are very few even half-modern apps that require
atime, and it really is best to run with noatime, saving the constant
access-time update writes.
The general kernel default is now relatime, which is a compromise that
works reasonably well on most filesystems, but even that tends to trigger
way more atime updates and thus de-dupped metadata when dealing with
btrfs snapshots than would be optimal.
Similarly, limited-write-cycle SSDs will do best with noatime. If you
happen to be running btrfs on ssd as I am, well...
So just run with noatime unless you are running something (like mutt)
that is known to need atimes, and then, preferably limit it to a
particular dedicated filesystem, perhaps choosing a filesystem other than
btrfs or at least a limited-snapshot btrfs.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
prev parent reply other threads:[~2013-08-25 10:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-23 9:38 default mount options 3.10 David Kofler
2013-08-23 10:29 ` Xavier Bassery
2013-08-23 12:58 ` Martin Steigerwald
2013-08-24 12:23 ` Duncan
2013-08-24 16:55 ` Chris Murphy
[not found] ` < pan$348ab$94e882cf$7b189911$f0786ffb@cox.net>
2013-08-25 10:29 ` Duncan [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='pan$1a1a3$f154c1a1$c83dacd2$30613a32@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.