>> [ ... ] more than likely your problem is that barriers have >> been enabled for MD/DM devices on the new kernel, and they >> aren't on the old kernel. [ ... ] > But didn't 2.6.38 replace barriers by explicit flushes the > filesystem has to wait for - mitigating most of the > performance problems with barriers? That's an example of the 'O_PONIES' attitude: because there are no performance problems with barriers as such. There is something completely different: a tradeoff between levels of safety (whether you want committed transactions or not and how finely grained) and time to completion. Barriers would have performance problems if given the safety semantics they offer they could be reimplemented to give better speed, but that does not seem to be the case. But when one sees comical "performance" comparisons without even cache flushing, explaining the difference between a performance problem and different safety/speed tradeoffs seems a bit wasted. Again, the fundamental problem is how many committed IOPS the storage system can do given a metadata (and thus journal) intensive load (the answer is "not many" per spinning medium). _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
