>>>> not expected by me; barriers == drive write cache flushes, which I
quoted text
>>>> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html