Re: [PATCH] ovl: Allow changing default fsync_mode

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/

>
> >
> >>
> >> Not quite sure applying a default volatile policy is quite feasible,
> >> especially the issue documented in
> >> https://github.com/containerd/containerd/pull/10274/files#diff-9239161e2af83fd84df5792f9fe64701c517fe4598eae60d4d245d039955f46cR33
> >>
> >> then userspace cannot drop `volatile` option as a somewhat
> >> workaround now.
> >
> > OS vendors can still set "auto" as the default config, while customers
> > can override it dynamically via sysfs. We have been running with
> > "volatile" on many production servers across different workloads for
> > over a year, and it has worked as expected without any issues.
>
> but sysfs setting still applies as system-wide, and there
> are some edge cases that we cannot apply volatile as
> default, that is my one concern.

It is unclear whether there are mixed workloads on the same server
that require both "volatile" and "strict" modes, but we have not
encountered such use cases across our large fleet of servers.

>
> The other concern is that since `volatile` omits fsync, so
> it's a posix violation (even that makes sense for container
> writable layers), not sure if we have to use it as the
> system-wide default configuration too.

We have use cases for setting this as a system-wide configuration. It
is unclear whether others have similar needs.

-- 
Regards
Yafang