linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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



  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).