Re: [PATCH] ovl: Allow changing default fsync_mode

(+try to cc more FS people for visibility.)

On 2026/6/23 20:47, Yafang Shao wrote:
> On Tue, Jun 23, 2026 at 7:59 PM Gao Xiang <[email protected]> wrote:
>>
>>
>>
>> On 2026/6/23 19:38, Yafang Shao wrote:
>>> On Tue, Jun 23, 2026 at 6:25 PM Gao Xiang <[email protected]> wrote:
>>>>
>>>>
>>>>
>>>> On 2026/6/23 18:18, Yafang Shao wrote:
>>>>> On Tue, Jun 23, 2026 at 6:12 PM Gao Xiang <[email protected]> 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.
> 
> It's your responsibility to handle the cases where "strict" is
> explicitly required. Please do your homework. It is not the kernel's
> fault.

How do you modify the existing applications and scripts
to adapt your incompatible new Kconfig?

> 
>>
>> 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.
> 
> It only adds a dynamically changeable config. Why do you insist it
> breaks everything? Users can always change it whenever they need.

Can you find any Kconfig option that changes user-visible
default functionality and causes almost any user
application that relies on remounting to fail to mount
again? If so, I think we should Cc Linus now.

Thanks,
Gao Xiang