From: Ric Wheeler <rwheeler@redhat.com>
To: Steve Brown <sbrown25@gmail.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: ext4 benchmark questions
Date: Fri, 23 Apr 2010 11:45:40 -0400 [thread overview]
Message-ID: <4BD1C0A4.6070102@redhat.com> (raw)
In-Reply-To: <k2n1f4ef0971004230838w8bfe6b2w41d9a68bf6bda9ee@mail.gmail.com>
On 04/23/2010 11:38 AM, Steve Brown wrote:
>>>>> not expected by me; barriers == drive write cache flushes, which I
>>>>> would never expect to speed things up...
>>>>>
>>>>>
>>>> hmmm... this would seem to conflict with the docs in the kernel,
>>>> especially:
>>>>
>>>> "Write barriers enforce proper on-disk ordering
>>>> of journal commits, making volatile disk write caches
>>>> safe to use, at some performance penalty. If
>>>> your disks are battery-backed in one way or another,
>>>> disabling barriers may safely improve performance."
>>>>
>>>>
>>> what you saw is in conflict with what is expected, yes; I don't know
>>> why barriers would ever increase performance.
>>>
>>> (my description of barriers as drive write caches isn't in conflict
>>> with the docs, I just said how they're implemented)
>>>
>>>
>> Barriers when working should never make things faster, at best, we should
>> have parity.
>>
>> Also important to note that barriers should be disabled if you hardware RAID
>> card exports itself as a "write through" cache, even if you enable barriers
>> on the command line.
>>
>> What controller are you using and what kind of drives do you have in the
>> back end?
>>
> Thats good to know about the write barriers with WT cache. I'm still
> setting everything manually in /etc/fstab because, well... I don't
> always trust software. ;)
>
> The controller is an LSI 9280-8e (megaraid_sas kernel module). Drives
> are 1TB Seagate ES.2s, 16 of them in the chassis.
>
> Steve
>
>
If you have the boot time log messages for the disks you use, you can
see how the cache is advertised to the kernel.
Also note that having battery backed RAID cards does not mean that your
drive's write cache will survive a power outage. You need to use vendor
specific tools usually to poke at the drives and make sure that the
write cache on the S-ATA disks is properly disabled (unless the LSI
firmware does something to manage the write cache on the drives).
Thanks!
Ric
next prev parent reply other threads:[~2010-04-23 15:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-22 21:38 ext4 benchmark questions Steve Brown
2010-04-22 21:52 ` Eric Sandeen
2010-04-22 22:11 ` Steve Brown
2010-04-22 22:20 ` Eric Sandeen
2010-04-23 14:42 ` Ric Wheeler
2010-04-23 15:38 ` Steve Brown
2010-04-23 15:45 ` Ric Wheeler [this message]
2010-04-23 15:49 ` Steve Brown
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=4BD1C0A4.6070102@redhat.com \
--to=rwheeler@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=sbrown25@gmail.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;
as well as URLs for NNTP newsgroup(s).