Re: why does ext4_sync_parent() bother with d_find_any_alias() at all?

On Sun, Apr 26, 2026 at 08:15:01AM +0100, Al Viro wrote:
> 
> What warranties is the entire thing trying to provide?  Anything
> that relies upon the order of dentries in the alias list is going to
> be quite brittle...

Originally, this was added not to provide *guarantees*, but just to
make things better in no-journal mode, where the parent directory
might not get written until 30 seconds later without a journal.

commit 14ece1028b3ed53ffec1b1213ffc6acaf79ad77c
Author: Frank Mayhar <[email protected]>
Date:   Mon May 17 08:00:00 2010 -0400

    ext4: Make fsync sync new parent directories in no-journal mode

    Add a new ext4 state to tell us when a file has been newly created; use
    that state in ext4_sync_file in no-journal mode to tell us when we need
    to sync the parent directory as well as the inode and data itself.  This
    fixes a problem in which a panic or power failure may lose the entire
    file even when using fsync, since the parent directory entry is lost.

    Addresses-Google-Bug: #2480057

    Signed-off-by: Frank Mayhar <[email protected]>
    Signed-off-by: "Theodore Ts'o" <[email protected]>

The use case that we were optimizing for was for newly created files,
and if the common an atomic write pattern wan't:

    fd = open("dir/foo.new");
    write(fd);
    link("dir/foo.new", "dir/foo");
    fsync(fd);

... but rather:

    fd = open("dir/foo.new");
    write(fd);
    rename("dir/foo.new", "dir/foo");
    fsync(fd);

So I'd say that what we are trying to do is to provide a best effort
attempt to avoid data loss in the face of crashes where (a) there is
only a single directory involved (e.g., where the application program
is renaming "foo.new" to "foo" in the original directory where
"foo.new" was created), and where there aren't other processes trying
to play fancy games with a newly created file.

This isn't documented as a guarantee; we're just trying to provide a
better experience for application programmers which don't realize that
POSIX requires that you fsync the directory if you really want strong
guarantees, on the theory that the application programmers vastly
outnumber the number of file system developers ---- and application
programmers tend do the darnest things :-)

In any case, because of this background, which an AI review bot would
have no hope of understanding, I think your patch is fine.  :-)


					- Ted

P.S.  We also have a similar, but unrelated "save the clueless
application programmer" hack where if the user does:

    fd = open("dir/foo.new");
    write(fd);
    close(fd)
    rename("dir/foo.new", "dir/foo");

... on the rename(), if foo.new was a newly created file, we will
initiate an asynchronous writeback.  This was a compromise where we
didn't want to impose a performance tax where it wasn't necessary, but
it was truly *shocking* how common the above pattern, sans any fsync
at all existed in many GNOME and KDE libraries, as well as the
TuxRacer game, where it would write the top-ten scoreboard, and then
close the 3D MESA library shortly thereafter, at which point the
proprietary Nvidia driver would crash the system, and users who lost
their 10 ten score were very sad.  :-)   This resulted in the whole
O_PONIES discussion / compromise in 2009:

    https://blahg.josefsipek.net/?p=364

Again, all of this is best efforts, and the philosophy is to work
around buggy userspace while minimizing performance overhead --- and
especially, *not* penalizing programs that do things correctly where
they are supposed to.