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

[Christoph Hellwig <hch@infradead.org>]

On Wed, Mar 25, 2026 at 02:11:31PM +0100, Amir Goldstein wrote:
> When an overlayfs file is modified for the first time, copy up will
> create a copy of the lower file and its parent directories in the upper
> layer.  Since the Linux filesystem API does not enforce any particular
> ordering on storing changes without explicit fsync(2) calls, in case
> of a system crash, the upper file could end up with no data at all
> (i.e. zeros), which would be an unusual outcome.  To avoid this
> experience, overlayfs calls fsync(2) on the upper file before completing
> data copy up with rename(2) to make the copy up "atomic".

Sounds good so far.

> By default, overlayfs does not call fsync(2) on copied up directories,
> so after a crash, a copied up directory could be observed in the upper
> layer without some of its attributes.

This does sound a bit scary.  How does a directory copy up work?
mkdir + adding the copies up entries, probably with some chmod or
chown thrown in?

> - "ordered": (default)
>     Call fsync(2) on upper file before completion of data copy up.
>     No fsync(2) is called on directory or metadata-only copy up.

"ordered" sounds like an odd name here.  It's more like lazy or
"nodirfsync".  And it might help to explain what this implies, which
is that the fsync on the files in the directory also sync the
directories out, because they are usually modified in the same
transaction, and a traditional simple log model implies that.  That
traditional single log model also implies that you get the metadata
file fsync for free in that case.  I.e. if you did:

	for each file:
		sync_file_range(file, .., SYNC_FILE_RANGE_WRITE |
				    SYNC_FILE_RANGE_WAIT_AFTER);

	fsync(dir)
	for each file:
		fsync(file)

at least for xfs (and probably the others) you should get the
performance of your ordered mode with the durability guarantees
of the strict version.