Just a couple of comments about barriers that might be worth throwing in the mix.
From what I have seen, running with barriers is almost always a win over running with write cache disabled for medium to large files (large files with a S-ATA drive go about twice as fast in my testing).
For very small files, running with the barrier or disabling the write cache are a lot closer in performance.
When we are looking for ways to batch, it is also critical to keep in mind the latency of the storage. The current ext3 transaction batching code makes running multi-threaded workloads on high speed media (like non-volatile disk arrays) run much slower. (Josef had some patches which helped fix this in a similar way that XFS deals with this.)
One other note is that moving to a FLASH based device will not make the issue of barriers go away since (most? all?) FLASH parts you are likely to see have their own write cache which is used to buffer up writes in order to make the erase cycle less painful. That means that we have a fairly large *volatile* write cache which needs to be flushed/controlled just like we do with S-ATA/SCSI/etc ;-)
ric -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
