Re: [PATCH] ovl: Allow changing default fsync_mode
Yafang Shao <[email protected]> Wed, 24 Jun 2026 10:09:50 +0800
| Newsgroups | org.kernel.vger.linux-unionfs,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CALOAHbBjhqKZPqb9r8qoUoYfzpEe6wYU9By_cZtuGGmnoaAa5g@mail.gmail.com> |
On Tue, Jun 23, 2026 at 10:52 PM Amir Goldstein <[email protected]> wrote: > > On Tue, Jun 23, 2026 at 3:47 PM Gao Xiang <[email protected]> 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/[email protected]/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