On Aug 24, 2009 16:10 -0400, Theodore Ts'o wrote: > However, even if we add even if we add per-block checksums, there is > still the problem that there is logic in the jbd layer where we avoid > reusing certain blocks until we are sure the transaction has > committed. With asynchronous commits, there is no way of knowing when > it is safe to reuse those blocks. AFAIK, "async commits" are not wholly async. There is still a wait for the transaction commit block to hit the disk before calling the transaction committed. The main improvement with "async commits" is that JBD only waits ONCE for both the transaction data blocks and the commit block (which are submitted at the same time). In particular note that there is an unconditional wait on the commit block for every transaction commit. JBD currently submits the transaction data and waits once for them to complete, and then submits the commit block and waits a second time for it to complete, which is 2x latency for every transaction. > Looking at the code, the best we can do in the short-term is to write > the commit record where we do, but do so with a barrier requested, and > then wait for the commit block where we do. This will provide some > performance improvement, since we won't wait for all of the journal > blocks to be sent to disk before writing the commit record. The big problem with Linux "barriers" is that they are actually cache flushes, so are worse than just having the original code that waits for completion of the actual journal blocks, because the "barrier" will force all kids of unrelated blocks to disk as well. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. -- 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
