lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 23 Apr 2010 11:45:40 -0400
From:	Ric Wheeler <rwheeler@...hat.com>
To:	Steve Brown <sbrown25@...il.com>
CC:	linux-ext4@...r.kernel.org
Subject: Re: ext4 benchmark questions

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


--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ