Re: [TOPIC] Extending the filesystem crash recovery guaranties contract

[Dave Chinner <david@fromorbit.com>]

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@fromorbit.com