Re: Re: [PATCH] fuse: skip lookup during atomic_open() when O_CREAT is set

[Horst Birthelmer <horst@birthelmer.de>]

On Thu, Feb 26, 2026 at 11:11:22PM +0000, Jim Harris wrote:
> 
> 
> > On Feb 24, 2026, at 8:33 AM, Miklos Szeredi <miklos@szeredi.hu> wrote:
> > 
> > External email: Use caution opening links or attachments
> > 
> > 
> > On Mon, 23 Feb 2026 at 19:55, Horst Birthelmer <horst@birthelmer.de> 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