Re: [PATCH] ovl: Allow changing default fsync_mode

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.

>
> 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.

>
> 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?

You'll need to restart the running services. When we applied
"volatile" with a livepatch across our large fleet of production
servers, everything worked fine without any breakage — we've done our
homework.

>
> 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"?

That's why it's a dynamically changeable config.
Again, pls do your homework.

-- 
Regards
Yafang