[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <k2n1f4ef0971004230838w8bfe6b2w41d9a68bf6bda9ee@mail.gmail.com>
Date: Fri, 23 Apr 2010 10:38:44 -0500
From: Steve Brown <sbrown25@...il.com>
To: linux-ext4@...r.kernel.org
Subject: Re: ext4 benchmark questions
>>>> 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
--
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