On Fri, May 03, 2019 at 05:58:46AM -0400, Theodore Ts'o wrote: > On Fri, May 03, 2019 at 12:16:32AM -0400, Amir Goldstein wrote: > > OK. we can leave that one for later. > > Although I am not sure what the concern is. > > If we are able to agree and document a LINK_ATOMIC flag, > > what would be the down side of documenting a RENAME_ATOMIC > > flag with same semantics? After all, as I said, this is what many users > > already expect when renaming a temp file (as ext4 heuristics prove). > > The problem is if the "temp file" has been hardlinked to 1000 > different directories, does the rename() have to guarantee that we > have to make sure that the changes to all 1000 directories have been > persisted to disk? No. Dependency creation is directional. If the parent directory modifies an entry that points to an inode, then the dependency (via inode link count modification) is created. Modifying an inode does not create a dependency on the parent directory, because the parent directory is not modified by inode specific changes. Yes, sometimes the dependency graph will resolve to fsync other directories. e.g. because hardlinks to the same inode were created and this is the first fsync on the inode that stabilises the link count. Because the link count is being stabilised, all the current depedencies on that link count (i.e. all the directories with uncommitted dirent modifications that modified the link count in that inode) /may/ be included in the fsync. However, if the filesystem tracks every change to the inode link count as separate modifications, it only need commit the directory modifications that occurred /before/ the one being fsync'd. i.e. SOMC doesn't require "sync the world" behaviour, it's just that we have filesysetms that currently behave that way because it's a simple and efficient way of tracking and resolving ordering dependencies. IOWs, SOMC is all about cross-object depedencies and how they are resolved. If you have no cross-object dependencies or your operations are isolated to a non-shared set of objects, then SOMC allows them to operate in 100% isolation to everything else and the filesystem can optimise this in whatever way it wants. SOMC is not the end of the world, Ted. It's just a consistency model that has been proposed that could allow substantial optimisation of application operations and filesystem behaviour. You're free to go in other directions if you want - diversity is good. :) Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
