Re: [PATCH] ovl: Allow changing default fsync_mode

On 2026/6/23 21:19, Yafang Shao wrote:
> On Tue, Jun 23, 2026 at 9:11 PM Gao Xiang <[email protected]> wrote:
>>
>>
>> (+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?
> 
> Why do you still insist it's "incompatible"? As far as I can see,
> mounting on the same directory is a very rare case, especially in
> production environments. If your use case relies on "strict", then
> simply don't turn it on. Everything across our large fleet of servers
> works perfectly well with it.

I've listed my reasons since this patch is really a red
line for me (otherwise I won't comment your patch, it's
none of my business.) and I've said enough, and the
upstream kernel + overlayfs does not work only for your
company:

You should first ask and gather how many existing
applications which can mount overlayfs will deal with
your new Kconfig; if not, what is the target audience
of your opt-in Kconfig other than your company as a way
to workaround "docker" upgrade.

Or if you'd like to introduce a new incompatible "overlayfs"
(an overlayfs cannot mount again by design + volatile by
default), I think we should name it as another fstype in
order to avoid breaking existing applications.

> 
>>
>>>
>>>>
>>>> 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.
> 
> I can't get you.
>