Matthias Buelow <[EMAIL PROTECTED]> writes: > Now my question is: Does FreeBSD also implements these barriers, or an > equivalent mechanism, as claimed on the above URL?
Do you have a background in OS design? It affects the answer, because you seem to be referring to access barriers and disk cache flushes interchangeably, which doesn't make sense, especially on multiprocessor systems. > If it does, why then > the frequent advice to disable write-back caching? Or is that only for > the couple drives that ignore any flush cache/disable wb commands? The problem with caching has nothing to do with flushing the cache; if you flush the cache often, there's no advantage to using it anyway. The whole speedup from using on-disk caching comes from the fact that the drive reorders the writes at will, and lies to the operating system by saying the writes are done when they aren't. Among other obvious problems, this negates the careful ordering calculated by softupdates. > I > know my drive doesn't ignore that command (since performance drops > sharply, when I disable the cache), so I would be on the safe side. This doesn't follow. Just because you know that your drive supports disabling the cache does not mean that it is safe to do so. > Would it be possible to get an authoritative statement from a FreeBSD > developer here on that matter? Could depend on how much you're willing to pay them. _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
