Re: [PATCH] ovl: Allow changing default fsync_mode

[Gao Xiang <hsiangkao@linux.alibaba.com>]

On 2026/6/23 17:59, Yafang Shao wrote:
> On Tue, Jun 23, 2026 at 5:49 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:

...

> 
>>
>>>
>>>>
>>>> The other concern is that since `volatile` omits fsync, so
>>>> it's a posix violation (even that makes sense for container
>>>> writable layers), not sure if we have to use it as the
>>>> system-wide default configuration too.
>>>
>>> We have use cases for setting this as a system-wide configuration. It
>>> is unclear whether others have similar needs.
>>
>> While I cannot speak out of overlayfs, but really it depends
>> on if the use cases is generic.
>>
>> Usually filesystems need to obey posix semantics as much as
>> possible, and using specific mount option to relax (violate)
>> some restriction, but it shouldn't be a system-wide stuff
>> since otherwise user applications cannot know if they really
>> live in the posix world.
> 
> AFAICS, the Linux kernel does not strictly follow POSIX in a number of areas.
> 
> BTW,
> 1. The "volatile" is not the default option.
> 2. Even when the system-wide default is set to "volatile", users can
> still change it per mount.

"
When overlay is mounted with "volatile" option, the directory
"$workdir/work/incompat/volatile" is created.  During next mount,
overlay checks for this directory and refuses to mount if present.
This is a strong indicator that the user should discard upper and
work directories and create fresh ones.
"

When the system-wide default is set to "volatile", it will become
a systemwide maintenance/compatiblity nightmare, at the very least,
if any overlayfs mount that needs to be remountable on these
systems (even something as small as a bash script that mounts an
overlayfs which must be remountable) they have to add "fsync=",
that needs application changes.

In my opinion, the argument "volatile is not the default option"
is not valid, since any reasonably robust userspace application
has to deal with _every visible Kconfig_ that could change the
kernel's default incompatible behavior. Otherwise, users who run
such applications on these kernels will inevitably complain.

On the other hand, I think the kernel itself should also be
responsible for ensuring that a new opt-in default remains
compatible with most existing userspace applications, regardless
of whether it is gated behind a Kconfig.

I don't think exposing incompatible default behavior, even behind
a new Kconfig, is okay without first reaching a sufficiently broad
audience.

Thanks,
Gao Xiang