On Thu, Jan 09, 2020 at 12:29:01PM +0800, xiaohui li wrote: > maybe i have not understand the difficulty of the fast commit coding work. > so I appreciate it very much if you give some more detailed > descriptions about the patches correlationship of v4 fast commit, > especially the reason why need have so many patches. > > from my viewpoint, the purpose of doing this fast commit function is > to resolve the ext4 fsync time-cost-so-much problem. > firstly we need to resolve some actual customer problems which exist > in ext4 filesystems when doing this fast commit function. > > so the first release version of fast commit is just only to accomplish > the goal of reducing the time cost of fsync because of jbd2 order > shortcoming described in ijournal paper from my opinion. > it need not do so many other unnecessary things. As Harshad has mentioned, one of the reasons why an incremental approach does not make sense is that once we release a version of fast commit into a mainline kernel, we have to worry about what happens if users start trying to use it, and we have to provide backwards compatibility for it. So if we were to break up fast commit into 5 parts, then we would have to allocate 5 feature bits, and we would have to support each version of fast commit --- essentially forever. As far as why are we doing this, we absolutely have a specific use case in mind, and that's to improve ext4's performance when used on a NFS server. The NFS protocol requires that any file system operation requested by a client is persisted before the server sends an acknowledgement back to the client. For the workloads that are heavy with metadata updates, avoiding the need to do a full jbd2 commit for every NFS RPC request which modifies metadata will a big difference to the NFS server's performance. This is why we are interested in making things like renames to be fast commit eligible, and not just the smaller set of system calls needed by (for example) SQLite. Regards, - Ted
