From: Stan Hoeppner <stan@hardwarefreak.com>
To: xfs@oss.sgi.com
Subject: Re: noatime,nodiratime?
Date: Wed, 19 May 2010 14:25:48 -0500 [thread overview]
Message-ID: <4BF43B3C.6030403@hardwarefreak.com> (raw)
In-Reply-To: <20100519182336.GA6264@infradead.org>
Christoph Hellwig put forth on 5/19/2010 1:23 PM:
> On Wed, May 19, 2010 at 09:13:38AM -0500, Stan Hoeppner wrote:
>> Need a little education here. I have a general understanding of what the
>> inode access timestamps "are" but I have no idea what, if any, applications
>> make use of these access times. I see posts all over Google land saying to
>> use "noatime,nodiratime,logbufs=8" for XFS mount options to increase
>> performance.
>
> Which doesn't make much sense. First 8 log buffers has been the default
> for XFS for a long time. Second nodiratime has always been useless as
> it is a strict subset of of noatime. Now noatime isn't the default yet,
> but instead relatime is, which still updates the atime in memory, but
> only writes it back when the inode has other changes, or on umount.
> It should give you equivalent performance to noatime, but better
> functionality.
Wow. That'll teach me to trust that man pages are accurate. :) Maybe you
could add this explanation about relatime vs noatime to the man page as well.
Any chance xfs_info could be updated to output the information we're
discussing, including spitting out the XFS specific mount options that are
currently active at the time of running xfs_info? There seems to be much
confusion in the community due to lack of accurate information being
available. Google for "XFS performance" and you'll see
"noatime,nodiratime,logbufs=8" mentioned consistently from early 2000's to
the present as a performance enhancer.
If what you say is true, on my 2.6.32.9 system, I actually decreased logbufs
from 8 to 4 half an hour ago, instead of increasing it from 2 to 4, as man
lead me to believe I was doing. Do any of the xfs tools output the XFS
specific active mount options allowing an op to confirm changes? As someone
else stated it would be nice to be able to see these parameter values. As
is, AFAICT, there's no way to confirm these parameter values.
--
Stan
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2010-05-19 19:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-19 14:13 noatime,nodiratime? Stan Hoeppner
2010-05-19 17:33 ` noatime,nodiratime? Nicolas KOWALSKI
2010-05-19 18:00 ` noatime,nodiratime? Stan Hoeppner
2010-05-19 18:24 ` noatime,nodiratime? Christoph Hellwig
2010-05-19 19:10 ` noatime,nodiratime? Nicolas KOWALSKI
2010-05-19 18:23 ` noatime,nodiratime? Christoph Hellwig
2010-05-19 19:25 ` Stan Hoeppner [this message]
2010-05-19 19:50 ` noatime,nodiratime? Eric Sandeen
2010-05-19 23:46 ` noatime,nodiratime? Stan Hoeppner
2010-05-26 14:53 ` noatime,nodiratime? Michael Monnerie
2010-05-26 23:18 ` noatime,nodiratime? Dave Chinner
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=4BF43B3C.6030403@hardwarefreak.com \
--to=stan@hardwarefreak.com \
--cc=xfs@oss.sgi.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox