Re: [PATCH] ovl: Allow changing default fsync_mode

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

On 2026/6/23 19:38, Yafang Shao wrote:
> On Tue, Jun 23, 2026 at 6:25 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>>
>>
>>
>> On 2026/6/23 18:18, Yafang Shao wrote:
>>> On Tue, Jun 23, 2026 at 6:12 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>>>>
>>
>> ...
>>
>>>>
>>>> Again, I don't want such customized messy breaks userspace
>>>> again; with that patch, container runtime needs to consider
>>>> if `volatile` is the default which just breaks the existing
>>>> containerd versions.
>>>
>>> I'll leave this debate to the overlayfs maintainers ;)
>>
>> On my own perspective and be responsible for common users
>> (and as a containerd maintainer [1]),
> 
> No wonder containerd is getting harder and harder to use ;)

What do you mean, can you explain exactly?

You're just adding a new way to break the existing
applications, no? You just breaks previous shipped
containerd.

Add a way to change the default behavior is fine, but
the new default behavior should be worked with the
same functionality and compatible, but switching to
`volatile` feature is non-compatible and what is why
containerd dropped volatile.

I've explained the technical reasons, can you also
show your technical argument why you cannot patch
docker with a very little change (if you can
livepatch the kernel) and just restart the docker
daemon, is that hard?  -- Also, is that requirement
common?

How pre-existing container runtime versions know
their default option is not "auto", how do they add
mount option "fsync=auto"? and how do they know there
is a new sysfs knob to work around incompatible
behavior?  there are so many container runtime
"docker", "containerd", "crio", how to make sure
all these container runtime aware of the new
default may not be "auto"?

Thanks,
Gao Xiang