Re: [PATCH] ovl: Allow changing default fsync_mode

[Gao Xiang]

On 2026/6/23 21:19, Yafang Shao wrote:
> On Tue, Jun 23, 2026 at 9:11 PM Gao Xiang <hsiangkao@xxxxxxxxxxxxxxxxx> 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 <hsiangkao@xxxxxxxxxxxxxxxxx> wrote:
> > > > On 2026/6/23 19:38, Yafang Shao wrote:
> > > > > On Tue, Jun 23, 2026 at 6:25 PM Gao Xiang <hsiangkao@xxxxxxxxxxxxxxxxx> wrote:
> > > > > > On 2026/6/23 18:18, Yafang Shao wrote:
> > > > > > > On Tue, Jun 23, 2026 at 6:12 PM Gao Xiang <hsiangkao@xxxxxxxxxxxxxxxxx> 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.