Re: [PATCH] ovl: Allow changing default fsync_mode

On Tue, Jun 23, 2026 at 6:12 PM Gao Xiang <[email protected]> wrote:
>
>
>
> On 2026/6/23 17:59, Yafang Shao wrote:
> > On Tue, Jun 23, 2026 at 5:49 PM Gao Xiang <[email protected]> wrote:
> >>
> >>
> >>
> >> On 2026/6/23 17:34, Yafang Shao wrote:
> >>> On Tue, Jun 23, 2026 at 5:25 PM Gao Xiang <[email protected]> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 2026/6/23 17:15, Yafang Shao wrote:
> >>>>> On Tue, Jun 23, 2026 at 5:00 PM Gao Xiang <[email protected]> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 2026/6/23 16:43, Yafang Shao wrote:
> >>>>>>> We have enabled "volatile" fsync_mode on our Kubernetes production
> >>>>>>> environment to prevent container exit from being blocked when there
> >>>>>>> are many dirty pages to flush. This has worked well without introducing
> >>>>>>> any issues.
> >>>>>>>
> >>>>>>> However, on some of our production servers, upgrading the container
> >>>>>>> runtime to support the "volatile" mount option is not straightforward [0].
> >>>>>>> To address this, we want to enable it by default within the kernel.
> >>>>>>
> >>>>>> Just a side note: "upgrade the container runtime is not
> >>>>>> straightforward", how? it seems that issue is already resolved and
> >>>>>> there is no more discussion.
> >>>>>
> >>>>> We still have many production servers running Docker, while the
> >>>>> "volatile" mount option is only supported by containerd. Upgrading
> >>>>> from Docker to containerd is a difficult process.
> >>>>
> >>>> But docker can be patched too: if upgrading the userspace is
> >>>> hard, why upgrading the linux kernel is easy?
> >>>
> >>> It is quite easy since the kernel can be livepatched without
> >>> rebooting. My employer is a heavy livepatch user. [1]
> >>>
> >>> [1]. https://lore.kernel.org/live-patching/
> >>
> >> It's just a generic opinion, in general, docker can be live
> >> upgraded without pausing the containers, and upgrading
> >> userspace is easier / safer than patching the kernel.
> >
> > Are you sure? How would one change an already mounted overlayfs that
> > was not enabled with "volatile"?
> >
> I don't see how your patch can apply to already mounted
> overlayfs.
>
> 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 ;)

-- 
Regards
Yafang