From: Michael Monnerie <michael.monnerie@is.it-management.at>
To: xfs@oss.sgi.com
Subject: Re: 3ware hardware raid with battery backup and the impact on barrier and no write cache options.
Date: Tue, 3 Nov 2009 09:36:25 +0100 [thread overview]
Message-ID: <200911030936.25442@zmi.at> (raw)
In-Reply-To: <alpine.DEB.2.00.0911021628030.811@p34.internal.lan>
On Montag 02 November 2009 Justin Piszcz wrote:
> I am also curious, I have a 16 drive RAID-6 configuration on a
> 9650SE-16ML and using -o nobarrier or mounting normal the
> speed/benchmarks seemed to be the same. Either barriers are not
> enabled by default for 3ware RAID arrays or they make no difference
> in performance?
I'd say a RAID controller with it's own write cache enabled + BBM will
effectively turn barriers off, even if you can use them as a mount
options. What happens with barriers, is that it writes
1,2,3,barrier,4,5,barrier,6 etc. so, that 123 are sure on disk before 45
happen etc.
The RAID controller will happily tell you it did flush everything,
because as soon as data is in it's cache, it's claimed sure that the
data gets written, and therefore it will tell that the barrier is
already done. And that's why it's a *must* to turn off disk cache
writes, because the filesystem got it's barrier ACK and believes it, the
controller has it's cache written to disk, powerfail.... all gone. That
will do a bigger damage than any single disk could have done.
mfg zmi
--
// Michael Monnerie, Ing.BSc ----- http://it-management.at
// Tel: 0660 / 415 65 31 .network.your.ideas.
// PGP Key: "curl -s http://zmi.at/zmi.asc | gpg --import"
// Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4
// Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2009-11-03 8:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-02 20:02 3ware hardware raid with battery backup and the impact on barrier and no write cache options William Lewis
2009-11-02 21:29 ` Justin Piszcz
2009-11-03 8:36 ` Michael Monnerie [this message]
2009-11-02 21:31 ` Eric Sandeen
2009-11-02 22:08 ` Michael Monnerie
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=200911030936.25442@zmi.at \
--to=michael.monnerie@is.it-management.at \
--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