From: Marc Lehmann <schmorp@schmorp.de>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: drastic changes to allocsize semantics in or around 2.6.38?
Date: Fri, 20 May 2011 17:49:20 +0200 [thread overview]
Message-ID: <20110520154920.GD5828@schmorp.de> (raw)
In-Reply-To: <20110520025659.GO32466@dastard>
On Fri, May 20, 2011 at 12:56:59PM +1000, Dave Chinner <david@fromorbit.com> wrote:
[thanks for the thorough explanation]
>
> So the question there: how is your workload accessing the files? Is
> it opening and closing them multiple times in quick succession after
> writing them?
I don't think so, but of course, when compiling a file, it will be linked
afterwards, so I guess it would be accessed at least once.
> I think it is triggering the "NFS server access pattern" logic and so
> keeping speculative preallocation around for longer.
Longer meaning practically infinitely :)
> I'd suggest removing the allocsize mount option - you shouldn't need
> it anymore because the new default behaviour resists fragmentation a
> whole lot better than pre-2.6.38 kernels.
I did remove it already, and will actively try this on our production
server which suffer from severe fragmentation (but xfs_fsr fixes that with
some work (suspending the logfile writing) anyway).
However, I would suggest that whatever heuristic 2.6.38 uses is deeply
broken at the momment, as NFS was not involved here at all (so no need for
it), the usage pattern was a simple compile-then-link-pattern (which is
very common), and there is really no need to cache this preallocation for
files that have been closed 8 hours ago and never touched since then.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schmorp@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-05-20 15:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-20 0:55 drastic changes to allocsize semantics in or around 2.6.38? Marc Lehmann
2011-05-20 2:56 ` Dave Chinner
2011-05-20 15:49 ` Marc Lehmann [this message]
2011-05-21 0:45 ` Dave Chinner
2011-05-21 1:36 ` Marc Lehmann
2011-05-21 3:15 ` Dave Chinner
2011-05-21 4:16 ` Marc Lehmann
2011-05-22 2:00 ` Dave Chinner
2011-05-22 7:59 ` Matthias Schniedermeyer
2011-05-23 1:20 ` Dave Chinner
2011-05-23 9:01 ` Christoph Hellwig
2011-05-24 0:20 ` Dave Chinner
2011-05-23 13:35 ` Marc Lehmann
2011-05-24 1:30 ` 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=20110520154920.GD5828@schmorp.de \
--to=schmorp@schmorp.de \
--cc=david@fromorbit.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 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.