From: L A Walsh <xfs@tlinx.org>
To: Dave Chinner <david@fromorbit.com>
Cc: Eric Sandeen <sandeen@sandeen.net>, linux-xfs@vger.kernel.org
Subject: Re: default mount options
Date: Wed, 30 Nov 2016 20:04:36 -0800 [thread overview]
Message-ID: <583FA154.9050905@tlinx.org> (raw)
In-Reply-To: <20161130221837.GH31101@dastard>
Dave Chinner wrote:
> For /some/ RAID controllers in /some/ modes. For example, the
> megaraid driver that has been ignoring cache flushes for over 9
> years because in RAID mode it doesn't need it. However, in JBOD
> mode, that same controller requires cache flushes to be sent because
> it turns off sane cache management behaviour in JBOD mode...
---
Lovely. For better or worse, none of my HW-based LSI-raid cards have
been able to do JBOD.
do JBOD.
> This is a clear example of why "barriers" should always be on and
> cache flushes always passed through to the storage - because we just
> don't know WTF the storage is actually doing with it's caches.
----
When it comes to JBOD, its not so clear about where caching
helps the most.
Related -- wondering about how external journals would
affect need for barriers. Haven't thought about it much, but it seems
like one would get alot of bang-for-the-buck to put journals on
SSD's. _If_ data written to SSD's becomes "safe" as soon as it is
accepted by SSDs (not saying it *is*, but _if_ it is), then how
"needed" is ordering of writes for rotating media -- apart from
special use/need cases like apps maintaining their own data-integrity
journals like DB's or such? Just wondering about how increasing use
of SSD's might affect the need for barriers.
Anyway, I have the illusion that I am mostly clear about
current params (at least until my next disillusioning)... ;-)
-l
next prev parent reply other threads:[~2016-12-01 4:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-29 23:51 Fwd: default mount options L.A. Walsh
2016-11-30 0:14 ` Eric Sandeen
2016-11-30 19:27 ` L A Walsh
2016-11-30 19:50 ` Eric Sandeen
2016-11-30 20:04 ` L A Walsh
2016-11-30 20:13 ` Eric Sandeen
2016-11-30 22:18 ` Dave Chinner
2016-12-01 4:04 ` L A Walsh [this message]
2016-12-01 10:50 ` 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=583FA154.9050905@tlinx.org \
--to=xfs@tlinx.org \
--cc=david@fromorbit.com \
--cc=linux-xfs@vger.kernel.org \
--cc=sandeen@sandeen.net \
/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.