Re: Re: [PATCH] fuse: skip lookup during atomic_open() when O_CREAT is set
From: Horst Birthelmer
Date: Fri Feb 27 2026 - 03:01:09 EST
On Thu, Feb 26, 2026 at 11:11:22PM +0000, Jim Harris wrote:
>
>
> > On Feb 24, 2026, at 8:33 AM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Mon, 23 Feb 2026 at 19:55, Horst Birthelmer <horst@xxxxxxxxxxxxx> wrote:
> >
> >> What is wrong with a compound doing LOOKUP + MKNOD + OPEN?
> >> If the fuse server knows how to process that 'group' atomically
> >> in one big step it will do the right thing,
> >> if not, we will call those in series and sort out the data
> >> in kernel afterwards.
> >>
> >> If we preserve all flags and the real results we can do pretty
> >> much exactly the same thing that is done at the moment with just
> >> one call to user space.
> >>
> >> That was actually what I was experimenting with.
> >>
> >> The MKNOD in the middle is optional depending on the O_CREAT flag.
> >
> > Okay, I won't stop you experimenting.
> >
> > My thinking is that it's simpler as a separate op (dir handle and name
> > are the same for LOOKUP and MKNOD). But adding this special "stop if
> > error or non-regular, else skip create if positive" dependency would
> > also work.
> >
> > Thanks,
> > Miklos
>
> Thanks for the feedback everyone. Sounds like compounds will be the way forward to optimize this path, once they are ready.
>
> Do we think compounds will be land for 7.1? Or later?
I honestly have no idea. I'm going as fast as I can.
BTW, the post you are responding to, wasn't meant to reject the patch IMHO, but the change in behavior could actually
become a real problem.
I have the same fear for the compound of open+getattr, which actually solves a bug, but could be trouble for
people making the wrong assumptions in their fuse servers.
>
> Best regards,
>
> Jim
>
Cheers,
Horst