Re: [PATCH] ovl: Allow changing default fsync_mode

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

Re: [PATCH] ovl: Allow changing default fsync_mode

[Yafang Shao]

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

I'm exhausted. We will keep this feature within our local kernel.

-- 
Regards
Yafang

Re: [PATCH] ovl: Allow changing default fsync_mode

[Christoph Hellwig]

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.

Re: [PATCH] ovl: Allow changing default fsync_mode

[Yafang Shao]

On Tue, Jun 23, 2026 at 9:42 PM Christoph Hellwig <hch@lst.de> 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.
>

Honestly surprised you haven't made it to my spam list ;)

-- 
Regards
Yafang

Re: [PATCH] ovl: Allow changing default fsync_mode

[Gao Xiang]

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@gmail.com/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.

Thanks,
Gao Xiang

Re: [PATCH] ovl: Allow changing default fsync_mode

[Amir Goldstein]

On Tue, Jun 23, 2026 at 3:47 PM Gao Xiang <hsiangkao@linux.alibaba.com> 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@gmail.com/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,
Amir.