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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
