Re: [PATCH] ovl: Allow changing default fsync_mode

On Tue, Jun 23, 2026 at 9:35 PM Gao Xiang <[email protected]> wrote:
>
>
>
> 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.

I'm exhausted. We will keep this feature within our local kernel.

-- 
Regards
Yafang