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