On Wed, Oct 23, 2019 at 04:58:47PM +0800, xiaohui li wrote: > why not let fsync handle enjoy one transaction exclusively ? > that is to say, in this transaction, there is only one handle which is > generated in one file's fsync path . There is only one handle which is generated in one file's fsync path. That isn't the problem. (If it were that simple, we would have done it a long time ago.) The problem is that there may have been other handles that have been started before the fsync transaction, and these handles will have already made changes to the file system. Worse, some of those handles may have made changes in the same metadata blocks which the fsync operation needs to modify. For example, suppose we are three seconds into the current transaction, with potentially hundreds of handles that have already been started and finished --- but not yet committed, because the current transaction hasn't closed. All of those handles have already been attached to the current transaction, and they can't be ignored. The fast commit patch set deals with this by using part of the journal for a "fast commit journal" where we essentially are doing a very simplified logical journal. It doesn't handle all cases, and there will be situations where we will need to fall back to the physical journalling techniques used in ext4 today. For example, if the file has been truncated, and then a single 4k block is written, and then the file gets fsync'ed, we won't be able to use the fast commit logical journal. Fortunately, the common case which compromises well over 99% of most workloads are much simpler to handle, and these can be handled via the fast commit patch. The fast commit approach is a simplified version of the idea proposed by Daejun Park and Dungkun Shih from the Sungkyunkwan University in Korea, and which were presented in the paper "iJournaling: Fine-Grained Journaling for Improving the Latency of Fsync System Call[1]", presented at the Usenix Annual Technical Conference in 2017. [1] https://www.usenix.org/conference/atc17/technical-sessions/presentation/park Cheers, - Ted