From: pg_xf2@xf2.for.sabi.co.UK (Peter Grandi)
To: Linux fs XFS <xfs@oss.sgi.com>
Subject: Re: xfs performance problem
Date: Fri, 29 Apr 2011 20:51:49 +0100 [thread overview]
Message-ID: <19899.5845.648007.218858@tree.ty.sabi.co.UK> (raw)
In-Reply-To: <201104291828.46420.Martin@lichtvoll.de>
>> [ ... ] more than likely your problem is that barriers have
>> been enabled for MD/DM devices on the new kernel, and they
>> aren't on the old kernel. [ ... ]
> But didn't 2.6.38 replace barriers by explicit flushes the
> filesystem has to wait for - mitigating most of the
> performance problems with barriers?
That's an example of the 'O_PONIES' attitude: because there are
no performance problems with barriers as such.
There is something completely different: a tradeoff between
levels of safety (whether you want committed transactions or not
and how finely grained) and time to completion.
Barriers would have performance problems if given the safety
semantics they offer they could be reimplemented to give better
speed, but that does not seem to be the case.
But when one sees comical "performance" comparisons without even
cache flushing, explaining the difference between a performance
problem and different safety/speed tradeoffs seems a bit wasted.
Again, the fundamental problem is how many committed IOPS the
storage system can do given a metadata (and thus journal)
intensive load (the answer is "not many" per spinning medium).
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-04-29 19:48 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-29 16:28 xfs performance problem Martin Steigerwald
2011-04-29 19:51 ` Peter Grandi [this message]
2011-05-01 16:56 ` Benjamin Schindler
-- strict thread matches above, loose matches on Subject: below --
2011-04-26 19:44 Benjamin Schindler
2011-04-26 22:12 ` Stan Hoeppner
2011-04-26 23:23 ` Benjamin Schindler
2011-04-26 23:59 ` Benjamin Schindler
2011-04-29 15:00 ` Peter Grandi
2011-04-30 20:36 ` Michael Monnerie
2011-05-01 8:49 ` Dave Chinner
2011-05-01 14:38 ` Peter Grandi
2011-05-01 15:08 ` Peter Grandi
2011-05-01 15:32 ` Michael Monnerie
2011-05-01 17:04 ` Peter Grandi
2011-05-02 2:50 ` Dave Chinner
2011-05-02 20:10 ` Emmanuel Florac
2011-05-01 13:33 ` Peter Grandi
2011-05-01 16:32 ` Peter Grandi
2011-04-27 7:55 ` Michael Weissenbacher
2011-04-27 8:09 ` Benjamin Schindler
2011-04-27 2:35 ` Dave Chinner
2011-04-29 16:27 ` Martin Steigerwald
2011-05-01 8:52 ` Dave Chinner
2011-05-01 16:55 ` Christoph Hellwig
2011-05-01 18:24 ` Markus Trippelsdorf
2011-05-02 10:14 ` Christoph Hellwig
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=19899.5845.648007.218858@tree.ty.sabi.co.UK \
--to=pg_xf2@xf2.for.sabi.co.uk \
--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