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.

Re: [PATCH] ovl: Allow changing default fsync_mode

[Yafang Shao]

On Tue, Jun 23, 2026 at 10:52 PM Amir Goldstein <amir73il@gmail.com> wrote:
>
> 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 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

Re: [PATCH] ovl: Allow changing default fsync_mode

[Gao Xiang]

On 2026/6/24 10:09, Yafang Shao wrote:
> On Tue, Jun 23, 2026 at 10:52 PM Amir Goldstein <amir73il@gmail.com> wrote:
>>
>> On Tue, Jun 23, 2026 at 3:47 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:

...

> 
> 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.
That is not an excuse to introduce such new incompatible behavior
to the linux upstream starting only for your customized fleet and
bother every single opensource user/application to adapt this
behavior which uses overlayfs now.

If you insist to work on a breaking change, please gather
userspace feedback boardly first.

And here I just say you and your employer are lucky since I
know it's also risky even on the generic kubernate perspective.
Please just maintain your livepatch downstream, thanks.

No need to reply, and I won't reply this either, it's just
waste of my time to explain a basic upstream principle again
and again.

Thanks,
Gao Xiang

Re: [PATCH] ovl: Allow changing default fsync_mode

[Yafang Shao]

On Wed, Jun 24, 2026 at 10:28 AM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>
>
>
> On 2026/6/24 10:09, Yafang Shao wrote:
> > On Tue, Jun 23, 2026 at 10:52 PM Amir Goldstein <amir73il@gmail.com> wrote:
> >>
> >> On Tue, Jun 23, 2026 at 3:47 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>
> ...
>
> >
> > 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.
> That is not an excuse to introduce such new incompatible behavior
> to the linux upstream starting only for your customized fleet and
> bother every single opensource user/application to adapt this
> behavior which uses overlayfs now.
>
> If you insist to work on a breaking change, please gather
> userspace feedback boardly first.
>
> And here I just say you and your employer are lucky since I
> know it's also risky even on the generic kubernate perspective.
> Please just maintain your livepatch downstream, thanks.
>
> No need to reply, and I won't reply this either, it's just
> waste of my time to explain a basic upstream principle again
> and again.

I'll just go ahead and redirect you to /dev/null ;)

-- 
Regards
Yafang

Re: [PATCH] ovl: Allow changing default fsync_mode

[Gao Xiang]

Hi,

On 2026/6/24 10:30, Yafang Shao wrote:
> On Wed, Jun 24, 2026 at 10:28 AM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>>
>>
>>
>> On 2026/6/24 10:09, Yafang Shao wrote:
>>> On Tue, Jun 23, 2026 at 10:52 PM Amir Goldstein <amir73il@gmail.com> wrote:
>>>>
>>>> On Tue, Jun 23, 2026 at 3:47 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>>
>> ...
>>
>>>
>>> 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.
>> That is not an excuse to introduce such new incompatible behavior
>> to the linux upstream starting only for your customized fleet and
>> bother every single opensource user/application to adapt this
>> behavior which uses overlayfs now.
>>
>> If you insist to work on a breaking change, please gather
>> userspace feedback boardly first.
>>
>> And here I just say you and your employer are lucky since I
>> know it's also risky even on the generic kubernate perspective.
>> Please just maintain your livepatch downstream, thanks.
>>
>> No need to reply, and I won't reply this either, it's just
>> waste of my time to explain a basic upstream principle again
>> and again.
> 
> I'll just go ahead and redirect you to /dev/null ;)

The whole thread is:
https://lore.kernel.org/linux-unionfs/20260623084337.54344-1-laoar.shao@gmail.com/T/#u

Personally, I feel offensive due to Yafang's expression
written above.  I keep maintain my replies in technical
discussion, but the replies above already include the
following words:

"No wonder containerd is getting harder and harder to use ;)"

"Please do your homework."

"Again, pls do your homework."

and the emotional texts `;)` make me feel uneasy over the
time,

especially the final words "I'll just go ahead and redirect
you to /dev/null ;)"

So I write an email as a public report to the CoC since I'm
not sure how to proceed to comment the community patches
because I could get offence as a result.

Thanks,
Gao Xiang

Re: [PATCH] ovl: Allow changing default fsync_mode

[Yafang Shao]

On Wed, Jun 24, 2026 at 11:17 AM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>
> Hi,
>
> On 2026/6/24 10:30, Yafang Shao wrote:
> > On Wed, Jun 24, 2026 at 10:28 AM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
> >>
> >>
> >>
> >> On 2026/6/24 10:09, Yafang Shao wrote:
> >>> On Tue, Jun 23, 2026 at 10:52 PM Amir Goldstein <amir73il@gmail.com> wrote:
> >>>>
> >>>> On Tue, Jun 23, 2026 at 3:47 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
> >>
> >> ...
> >>
> >>>
> >>> 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.
> >> That is not an excuse to introduce such new incompatible behavior
> >> to the linux upstream starting only for your customized fleet and
> >> bother every single opensource user/application to adapt this
> >> behavior which uses overlayfs now.
> >>
> >> If you insist to work on a breaking change, please gather
> >> userspace feedback boardly first.
> >>
> >> And here I just say you and your employer are lucky since I
> >> know it's also risky even on the generic kubernate perspective.
> >> Please just maintain your livepatch downstream, thanks.
> >>
> >> No need to reply, and I won't reply this either, it's just
> >> waste of my time to explain a basic upstream principle again
> >> and again.
> >
> > I'll just go ahead and redirect you to /dev/null ;)
>
> The whole thread is:
> https://lore.kernel.org/linux-unionfs/20260623084337.54344-1-laoar.shao@gmail.com/T/#u
>
> Personally, I feel offensive due to Yafang's expression
> written above.  I keep maintain my replies in technical
> discussion, but the replies above already include the
> following words:
>
> "No wonder containerd is getting harder and harder to use ;)"
>
> "Please do your homework."
>
> "Again, pls do your homework."
>
> and the emotional texts `;)` make me feel uneasy over the
> time,
>
> especially the final words "I'll just go ahead and redirect
> you to /dev/null ;)"
>
> So I write an email as a public report to the CoC since I'm
> not sure how to proceed to comment the community patches
> because I could get offence as a result.

I believe you could learn a thing or two from Amir about how to
comment on others' patches ;)

-- 
Regards
Yafang

Re: [PATCH] ovl: Allow changing default fsync_mode

[Gao Xiang]

On 2026/6/24 11:28, Yafang Shao wrote:
> On Wed, Jun 24, 2026 at 11:17 AM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>>
>> Hi,
>>
>> On 2026/6/24 10:30, Yafang Shao wrote:
>>> On Wed, Jun 24, 2026 at 10:28 AM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>>>>
>>>>
>>>>
>>>> On 2026/6/24 10:09, Yafang Shao wrote:
>>>>> On Tue, Jun 23, 2026 at 10:52 PM Amir Goldstein <amir73il@gmail.com> wrote:
>>>>>>
>>>>>> On Tue, Jun 23, 2026 at 3:47 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>>>>
>>>> ...
>>>>
>>>>>
>>>>> 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.
>>>> That is not an excuse to introduce such new incompatible behavior
>>>> to the linux upstream starting only for your customized fleet and
>>>> bother every single opensource user/application to adapt this
>>>> behavior which uses overlayfs now.
>>>>
>>>> If you insist to work on a breaking change, please gather
>>>> userspace feedback boardly first.
>>>>
>>>> And here I just say you and your employer are lucky since I
>>>> know it's also risky even on the generic kubernate perspective.
>>>> Please just maintain your livepatch downstream, thanks.
>>>>
>>>> No need to reply, and I won't reply this either, it's just
>>>> waste of my time to explain a basic upstream principle again
>>>> and again.
>>>
>>> I'll just go ahead and redirect you to /dev/null ;)
>>
>> The whole thread is:
>> https://lore.kernel.org/linux-unionfs/20260623084337.54344-1-laoar.shao@gmail.com/T/#u
>>
>> Personally, I feel offensive due to Yafang's expression
>> written above.  I keep maintain my replies in technical
>> discussion, but the replies above already include the
>> following words:
>>
>> "No wonder containerd is getting harder and harder to use ;)"
>>
>> "Please do your homework."
>>
>> "Again, pls do your homework."
>>
>> and the emotional texts `;)` make me feel uneasy over the
>> time,
>>
>> especially the final words "I'll just go ahead and redirect
>> you to /dev/null ;)"
>>
>> So I write an email as a public report to the CoC since I'm
>> not sure how to proceed to comment the community patches
>> because I could get offence as a result.
> 
> I believe you could learn a thing or two from Amir about how to
> comment on others' patches ;)

;) Please let me know why you commented:

"No wonder containerd is getting harder and harder to use ;)"

;)

Thanks,
Gao Xiang

> 

Re: [PATCH] ovl: Allow changing default fsync_mode

[Yafang Shao]

On Wed, Jun 24, 2026 at 11:36 AM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
>
>
>
> On 2026/6/24 11:28, Yafang Shao wrote:
> > On Wed, Jun 24, 2026 at 11:17 AM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
> >>
> >> Hi,
> >>
> >> On 2026/6/24 10:30, Yafang Shao wrote:
> >>> On Wed, Jun 24, 2026 at 10:28 AM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 2026/6/24 10:09, Yafang Shao wrote:
> >>>>> On Tue, Jun 23, 2026 at 10:52 PM Amir Goldstein <amir73il@gmail.com> wrote:
> >>>>>>
> >>>>>> On Tue, Jun 23, 2026 at 3:47 PM Gao Xiang <hsiangkao@linux.alibaba.com> wrote:
> >>>>
> >>>> ...
> >>>>
> >>>>>
> >>>>> 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.
> >>>> That is not an excuse to introduce such new incompatible behavior
> >>>> to the linux upstream starting only for your customized fleet and
> >>>> bother every single opensource user/application to adapt this
> >>>> behavior which uses overlayfs now.
> >>>>
> >>>> If you insist to work on a breaking change, please gather
> >>>> userspace feedback boardly first.
> >>>>
> >>>> And here I just say you and your employer are lucky since I
> >>>> know it's also risky even on the generic kubernate perspective.
> >>>> Please just maintain your livepatch downstream, thanks.
> >>>>
> >>>> No need to reply, and I won't reply this either, it's just
> >>>> waste of my time to explain a basic upstream principle again
> >>>> and again.
> >>>
> >>> I'll just go ahead and redirect you to /dev/null ;)
> >>
> >> The whole thread is:
> >> https://lore.kernel.org/linux-unionfs/20260623084337.54344-1-laoar.shao@gmail.com/T/#u
> >>
> >> Personally, I feel offensive due to Yafang's expression
> >> written above.  I keep maintain my replies in technical
> >> discussion, but the replies above already include the
> >> following words:
> >>
> >> "No wonder containerd is getting harder and harder to use ;)"
> >>
> >> "Please do your homework."
> >>
> >> "Again, pls do your homework."
> >>
> >> and the emotional texts `;)` make me feel uneasy over the
> >> time,
> >>
> >> especially the final words "I'll just go ahead and redirect
> >> you to /dev/null ;)"
> >>
> >> So I write an email as a public report to the CoC since I'm
> >> not sure how to proceed to comment the community patches
> >> because I could get offence as a result.
> >
> > I believe you could learn a thing or two from Amir about how to
> > comment on others' patches ;)
>
> ;) Please let me know why you commented:
>
> "No wonder containerd is getting harder and harder to use ;)"
>
> ;)

Because I find it harder to use than Docker ;)

-- 
Regards
Yafang