Re: [PATCH] ovl: make fsync after metadata copy-up opt-in mount option

[Amir Goldstein <amir73il@gmail.com>]

On Wed, Mar 25, 2026 at 6:55 AM Christoph Hellwig <hch@infradead.org> wrote:
>
> On Tue, Mar 24, 2026 at 03:57:50PM +0100, Amir Goldstein wrote:
> > From: Fei Lv <feilv@asrmicro.com>
> >
> > Commit 7d6899fb69d25 ("ovl: fsync after metadata copy-up") was done to
> > fix durability of overlayfs copy up on an upper filesystem which does
> > not enforce ordering on storing of metadata changes (e.g. ubifs).
>
> I'm trying to understand this previous commit more than this one,
> but what 'enforce ordering on storing of metadata changes' does
> overlayfs encode right now?

On copy up or a directory:
1. create a directory in tmpdir
2. copy attributes and xattr from lower directory to this staged
directory copy up
3. move it into place in overlayfs upperdir

Until commit 7d6899fb69d25, there was no fsync before step 2 to 3.
Only when copying a regular file there was fsync after data copy up.

This of course provides no guarantee over the state of the copied up dir
after crash, whether the directory is observed in upperdir with or without
the attributes, but in reality this is how it is since 2014 and for many local
filesystems (e.g. xfs), there is little risk in this practice.

It should be noted that overlayfs is quite picky about which filesystems
are allowed as upper filesystems and specifically network filesystems
are not allowed.

> There is no real ordering requirements
> anywhere in the Linux file system API, so it does sounds like ovl
> is making some assumptions by default?

Correct. I would say "making assumptions" I would just say that
overlayfs has never taken this aspect into account.

> Are those documented somewhere?

I guess not, but now that this commit introduces, fsync=ordered,strict
and a documentation section about them, it is a good opportunity
to expand on this point. I will add that.

Thanks for pointing this out.

Amir.