Re: [PATCH] ovl: Allow changing default fsync_mode
From: Yafang Shao
Date: Tue Jun 23 2026 - 22:10:49 EST
On Tue, Jun 23, 2026 at 10:52 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>
> On Tue, Jun 23, 2026 at 3:47 PM Gao Xiang <hsiangkao@xxxxxxxxxxxxxxxxx> wrote:
> >
> > Hi Christoph,
> >
> > On 2026/6/23 21:42, Christoph Hellwig wrote:
> > > I have no idea where this coming from as I can't find an earlier
> > > version in the fsdevel archives. But changing user visible mount
> > > options through konfig options is simply bonkers.
> > >
> > > I'd also like to not that the submitter does have a history of crazy
> > > patches including those to support proprietary modules and then
> > > attacking people criticizing those patches, so I can only suggest to
> > > every maintainer to ignore them for their own sanity.
> >
> > Sorry about that I didn't Cc the proper list at first,
> > but it could be checked by using lore:
> > https://lore.kernel.org/linux-unionfs/20260623084337.54344-1-laoar.shao@xxxxxxxxx/T/#u
> >
> > This topic is very specific to overlayfs details, I'm
> > not sure how I could say the background in brief.
> >
> > But almost every single container user uses overlayfs
> > now, so in order to be responsible for end users,
> > container runtimes and applications, I used some
> > aggressive way this time.
>
> Gao,
>
> Thank you for holding the fort!
> and for foreseeing this containerd regression.
>
> I also agree with all your other arguments that "volatile" should never be the
> system/module default - it is too risky - one needs to know what they are doing
> when using "volatile".
>
> I will respect your NACK.
>
> Yafang,
>
> I agree with you that your patch appears to follow precedents
> in overlayfs, but I also think that "volatile" is not a good candidate for
> this practice, mostly because it makes mount cycle fail.
>
> Since it is so much easier for your employer to live patch the kernel
> than to upgrade/patch docker, how about applying this live patch to
> your kernels?
>
> diff --git a/fs/overlayfs/params.c b/fs/overlayfs/params.c
> index c93fcaa45d4a3..2105a51d12439 100644
> --- a/fs/overlayfs/params.c
> +++ b/fs/overlayfs/params.c
> @@ -155,7 +155,7 @@ static const char *ovl_fsync_mode(struct ovl_config *config)
>
> static int ovl_fsync_mode_def(void)
> {
> - return OVL_FSYNC_AUTO;
> + return OVL_FSYNC_VOLATILE;
> }
Thanks for your guidance. This is similar to how we handle
livepatching, and we also implement the "volatile" option for
already-mounted systems.
Since the "volatile" option has been working fine for over a year
across our large fleet of Kubernetes production servers, I submitted
this change to upstream. In Kubernetes environments, there is no use
case for remounting the workdir to the same directory, so the volatile
file won't cause any issues — which is why the "volatile" setting has
been working well there. But yeah, I respect your decision not to
accept it.
--
Regards
Yafang